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SC30-3409, THE X.25 1984/1988 DTE/DCE and DTE/DTE INTERFACE ARCHITEC- 
TURE REFERENCE describes the protocols, formats and procedures for the 
three layers - physical, data link and packet - of the X.25 DTE/DCE and DTE/DTE 
interfaces, as well as the logical link control(s) employed by IBM SNA X.25 
DTEs on both SNA-to-SNA and SNA-to-non_ SNA connections. | 
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Preface 


This manual describes the elements, including optional user facilities, of CCITT 
Recommendation X.25 - INTERFACE BETWEEN DATA TERMINAL EQUIPMENT 
(DTE) AND DATA CIRCUIT TERMINATING EQUIPMENT (DCE) FOR TERMINALS 
OPERATING IN THE PACKET MODE ON PUBLIC DATA NETWORKS (Geneva, 
1976; amended Geneva, 1980; Malaga-Torremolinos, 1984; and Melbourne, 1988) 
- that are applicable to IBM SNA network nodes that can attach to X.25-based 
Packet-Switched Data Networks (PSDNs). It is based on the version of CCITT 
Recommendation X.25 adopted by the IXth Plenary Assembly in 1988 as pub- 
lished in the ‘Blue Books’. 


Excerpts from CCITT Recommendation X.25 (Melbourne, November 1988), 
including sections 1.1 - 1.2, 2.1- 2.5, 3.1- 3.5, 41-46, 5.1 -6.6, 5.7.2, 6.1 - 6.28, 
7.1 - 7.3, Annex A, Annex B, Annex C, Annex D, Annex E, Annex F and Annex G 
are reprinted in this manual. 


IBM SNA data terminal equipment (DTEs) that use the X.25 recommendation to 
interface to PSDN data circuit-terminating equipment (DCEs) are referred to in 
this document as IBM SNA X.25 DTEs. Elements of CCITT Recommendation 
X.25 (1988) are selected by IBM to support three basic categories of con- 
nections: 


a. SNA-to-SNA: 


connections between SNA X.25 DTEs, either via direct attachment; or via 
virtual calls or permanent virtual circuits, or both, through intervening 
packet-switched data network(s); are accommodated. 


b. SNA-to-non_SNA: 


connections between SNA X.25 DTEs and non-SNA X.25 DTEs, either via 
direct attachment; or via virtual calls or permanent virtual circuits, or- 
both, through intervening packet-switched data network(s); are accom- 
modated. 


c. OSI.N_ connections 


between X.25 Packet-Mode DTEs, either via direct attachment; or, via 
virtual calls or permanent virtual circuits, or both, through intervening 
packet-switched data network(s); are accommodated. 


The DTE/DCE and DTE/DTE interfaces for SNA-to-SNA connections, 
SNA-to-non_SNA connections and OSI.N_ connections differ only at the packet 
layer; therefore, the definitions and descriptions of the physical layer and the 
data link layer apply equally to all three types of connections. 


Information in this manual must not be construed as describing any specific 
IBM product (machine or program) or service. Neither can it be construed to 
mean that all or any specific IBM products necessarily provide only, or all of, 
the X.25 DTE/DCE or DTE/DTE interface functions described herein. 


In addition, note that the ELLC, QLLC and PSH Protocols defined in this manual 
describe existing implementations of end-to-end control functions that are 
required above the X.25 DTE/DCE Interface. Further end-to-end controls appli- 
cable for use with X.25-based network services may be implemented as 
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requirements become more clearly identified. Readers are cautioned to refer 
to appropriate IBM product description and operation manuals for information 
regarding the availability and characteristics of X.25 DTE/DCE interface func- 
tions supported by specific IBM products. 


The reader is assumed to be conversant with both CCITT Recommendation X.25 
and SNA. A list of applicable references is included in a companion General 
Information Manual, GA27-3761, to help the less informed reader to understand 
these subjects. | 


CCITT Recommendation X.25 (Melbourne, November 1988), like it’s predecessor 
(Malaga-Torremolinos, October, 1984), defines an interface between customer 
data terminal equipment (DTE) and data circuit-terminating equipment (DCE). It 
is designed to facilitate the attachment of DTEs to packet-switched data net- 
works (PSDNs). The definition includes three independent elements: 


1. Physical Layer - the mechanical, electrical, functional and proce- 
dural characteristics to activate, maintain and deactivate physical 
communication links between DTEs and DCEs. 


2. Data Link Layer - the link access procedure for the interchange of 
data across communication links between DTEs and DCEs. 


3. Packet Layer - the packet formats and control procedures for the 
exchange of control information or user data, or both, between 
DTEs and DCEs. 


Other international standards explicitly or implicitly reflected in this specifica- 
tion include: 


« CCITT Recommendation X.1 - International User Classes of Service in 
Public Data Networks and Integrated Services Digital Networks (ISDN); 


e CCITT Recommendation X.2 - International Data Transmission Ser- 
vices and Optional User Facilities in Public Data Networks; 


e CCITT Recommendation X.21 - Interface between Terminal Equipment 
(DTE) and Data Circuit-Terminating Equipment (DCE) for Synchronous 
Operation on Public Data Networks; 


« CCITT Recommendation X.21_ bis - Use on Public Data Networks of 
Data Terminal Equipment (DTE) which are Desioned for Interfacing to 
Synchronous V-Series Modems; 


« CCITT Recommendation X.31 - Support of Packet Mode Terminal 
Equipment by an ISDN; 


e CCITT Recommendation X.32 - Interface between Data Terminal Equip- 
ment (DTE) and Data Circuit-Terminating Equipment (DCE) for termi- 
nals operating in a packet mode and accessing a packet switched 
public data network through a public switched telephone network or 
an integrated services digital network or a circuit switched public data 
network; 


¢ CCITT Recommendation X.96 - Call Progress Signals in Public Data 
Networks; 


¢ CCITT Recommendation X.110 - Routing Principles for International 
Public Data.Services through Switched Public Data Networks of the 
Same Type; 
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¢ CCITT Recommendation X.121 - International Numbering Plan for 
Public Data Networks; 


« CCITT Recommendation X.200 - Reference Model of Open Systems 
Interconnection for CCITT Applications; 


« CCITT Recommendation X.213 - Network Service Definition for Open 
systems Interconnection for CCITT Applications; 


« CCITT Recommendation X.223 - Use of X.25 Packet Layer Protocol to 
provide the OSI Connection Mode Network Service; 


¢ CCITT Recommendation X.244 - Procedure for the Exchange of Pro- 
tocol Identification During Virtual Call Establishment on Packet- 
switched Public Data Networks; 


« CCITT Recommendation X.301 - Description of the General Arrange- 
ments for Call Control within a Subnetwork and between Subnetworks 
for the Provision of Data Transmission Services; 


© |SO-8348 - Open Systems Interconnection (OSI) - Network Service Defi- 
nition; 

e |SO-7776 - Description of the X.25 LAPB-compatible DTE Data Link Pro- 
cedures; 


e |SO-7498 - Information processing systems - Open Systems Intercon- 
nection - Basic Reference Model; 


= 1S0-8208 - X.25 Packet Layer Protocol! for Data Terminal Equipment; 


e |SO-8878 - Information Processing Systems - Data Communications - 
Use of X.25 to provide the OSI connection-mode network service; 


e |SO-8880-2 - Information Processing Systems - Data Communications - 
Support of the connection-mode network service; and, 


e ANS X3.100 - Interface between Data Terminal Equipment (DTE) and 
Data Circuit-Terminating Equipment (DCE) for Operation with Packet- 
Switched Data Networks (PSDN), or between two DTEs, by Dedicated 
Circuit. 


This document supports communication between a DTE and a DCE or between 
two DTEs without an intervening network. Since one of those DTEs will be 
acting as a DCE, the term DTE/DTE can be substituted for the term DTE/DCE in 
the following paragraphs. 


A companion document, GA27-3761, The X.25 1984/1988 Interface for Attaching 
IBM SNA Nodes to Packet-Switched Data Networks - General Information 


Manual, describes the elements of CCITT Recommendation X.25_ 1984/1988 
selected for implementation in IBM SNA X.25 1988 DTEs that adhere to Systems 
Network Architecture (SNA). 


CCITT Recommendation X.25 1988 focuses on a description of the DTE/DCE 
interface functions from the perspective of DCEs. This manual focuses on the 
same interface from the perspective of DTEs. Thus, many instances occur 
where the term DTE or DCE is replaced by the word station({s). Other substan- 
tive differences between the two interface descriptions and SC30-3409-0 are 
identified by symbols in the left margin of this document. Text included herein 
that: 
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- is essentially the same as that contained in CCITT Recommendation 
X.25 (Melbourne, November 1988) and that contained in SC30-3409-0 is 
unmarked: 


- is essentially the same as that contained in CCITT Recommendation 
X.25 (Melbourne, November 1988) but differs substantially from that 
contained in SC30-3409-0 is identified by greater than symbols (>) in 
the left margin of this document; 


- differs substantially from that contained in CCITT Recommendation 
X.25 (Melbourne, November 1988) and that contained in SC30-3409-0 is 
identified by plus signs (+) in the left margin of this document; 


- is extracted from ISO-7776, ISO-8208 or ANS x3.100 for elaboration or 
clarification and is identified by the letter s in the left margin of this 
document. 


DCE operation as described in CCITT Recommendation X.25 (1988) is retained 
here for comparative purposes. 


Notes: 


1. The bit/byte numbering used throughout this specification is con- 
sistent with the numbering used in CCITT Recommendation X.25 
and may, therefore, differ from that with which the reader may be 
more familiar. 


2. Network specific interface requirements, that deviate from the 
interpretation of CCITT Recommendation X.25 (Melbourne, 
November 1988), ISO 7776, ISO 8208 or ANS x3.100 reflected in this 
document, may be considered by IBM SNA X.25 Product Managers 
on an individual basis, in making technical and business judge- 
ments regarding possible justification for the support of such 
deviation(s). Network specific requirements are not defined in this 
manual. 


This manual complies with, and ts patterned after, the version of CCITT Recom- 
mendation X.25 adopted by the IXth Plenary Assembly at Melbourne and sub- 
sequently published in the ‘Blue Book.’ It also complies with requirements set 

forth in ANS-X3.100, ISO-7776, ISO 8208, and ISO-8878 for the provision of | 
Network Layer services in Open Systems. It is composed of nine chapters and 

several appendixes, as follows: 


Chapter 1 - DTE/DCE Interface Characteristics 


specifies the physical layer interface used between IBM SNA X.25 
DTEs and their associated DCEs. 


Chapter 2 - Link Access Procedure Across the DTE/DCE Interface 


specifies the data link layer interface used for the interchange of 
data via communication links between IBM SNA X.25 DTEs and their 
associated DCEs. 


Chapter 3 - Description of the Packet Layer DTE/DCE Interface 


describes the packet layer procedures used to exchange control 
information and user data at the X.25 DTE/DCE interface. 


Chapter 4 - Procedures for Virtual Circuit Services 
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describes the procedures used for virtual call and permanent virtual 
circuit Services. 


Chapter 5 - Packet Formats 


specifies the formats for packets exchanged between IBM SNA X.25 
DTEs and their associated DCEs. 


Chapter 6 - Procedures for Optional User Facilities (Packet Layer) 


describes the optional packet layer user facilities and specifies pro- 
cedures for their selection and use. 


Chapter 7 - Formats for Facility Fields and Registration Fields 


Specifies the formats for facility fields and registration fields for 
optional user facilities. 


Chapter 8 - Logical Link Control (LLC) on SNA-to-SNA Connections 


introduces the adjacent node protocols (logical link controls) 
employed by IBM SNA X.25 DTEs in PSDN environments to perform 
ONA adjacent node physical services. 


Chapter 9 - Other System Considerations 


describes some other considerations for the use of IBM SNA X.25 
DTEs in Packet-Switched Data Network environments. 


Appendix A - Logical Channel Ranges 


defines the ranges of logical channels used for virtual calls and 
permanent virtual circuits. 


Appendix B - Packet Layer DTE/DCE Interface State Diagrams 


defines the packet layer state transitions at the X.25 DTE/DCE inter- 
face. 


Appendix C - Packet Layer DCE Actions 


describes the actions taken by DCEs on receipt of packets in a 
given state of the packet iayer X.25 DTE/DCE interface as perceived 
by DCEs. 


Appendix D - DCE Time-outs and DTE Time-limits 
defines packet layer DCE time-outs and DTE time-limits. 
Appendix E - Network Generated Diagnostic Codes 


specifies the diagnostic codes generated by DCEs employing CCITT 
Recommendation X.25 for CLEAR INDICATION, RESET INDICATION, 
RESTART INDICATION and DIAGNOSTIC packets. 


Appendix F - On-Line Registration Facility Applicability 


defines applicability of the on-line registration facilities to other 
facilities. 


Appendix G - CCiTT-Specified DTE Facilities 
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describes CClTT-Specified_ DTE facilities that may be passed 
unchanged between communicating DTEs to support end-to-end sig- 
nalling required by the OSI Network Service. 


Appendix H - SNA-to-SNA Diagnostic Codes 


specifies the diagnostic codes generated by IBM SNA X.25 DTEs for 
CLEAR REQUEST, RESET REQUEST and RESTART REQUEST 
packets on SNA-to-SNA connections. 


Appendix | - Packet Layer DTE Actions 


describes the actions taken by IBM SNA X.25 DTEs on receipt of 
packets in a given state of the packet layer of the X.25 DTE/DCE 
interface as perceived by DTEs. 


Appendix J - Physical Services Headers 


describes the Physical Services Header (PSH) used on SNA-to-SNA 
connections to an IBM 5973 Network Interface Adapter (NIA). 


Appendix K - SNA-to-Non_SNA Architectural Corsiderations 


describes some architectural considerations for SNA-to-non SNA 
connections. | 


Appendix L - LAPB SLP Finite State Machines 


describes the actions taken by IBM SNA X.25 DTEs upon occurrence 
of events in the various states of the data link layer SLP interface. 


Appendix M - Description of the Enhanced Logical Link Control (ELLC) Pro- 
cedures | 


describes the actions taken by IBM SNA X.25 DTEs upon occurrence 
of events in the various states of the interface for ELLC. 


Appendix N - X.25_1980/1984/1988 Compatibility Considerations 


describes limitations that may be imposed on the use of X.25 1984 
and X.25 1988 functions and formats for compatibility with specific 
X.25 DTE/DCE Interface implementations that comply with CCITT 
Recommendation X.25_ 1980. 


Appendix O - Description of the BNN Qualified Logical Link Control - (QLLC) 
Procedures 


describes the protocols, formats and procedures employed by IBM 
SNA X.25_ 1988 DTE Boundary Network Nodes for Qualified Logical 
Control on SNA-to-SNA connections. 


Appendix V - Information on Addresses in Call Set-up and Clearing Packets 


describes the two components a DTE address may include: a main 
address and a complementary address as defined in CCITT Recom- 
mendation X.25 (Melbourne, 1988). 


Architecture Reference 


Contents 


X.25 DTE/DCE and DTE/DTE Interface 


Chapter 1. DTE/DCE Interface Characteristics nace Layer) ....... 1-1 

CCITT Recommendation X.21 2... 2. ee ee 1-1 

DTE/DCE Physical Interface Elements ..................... 1-1 

Procedures for Entering Operational Phases ................ 1-1 

Failure Detection and Test Loops ..................0.2. 200. 1-2 

SIGNal Clement TIMING. °3. 4.6 web ww, & od be ee BEE 2 er ee ONS SR 1-3 

Recommendation X.21 bis Interface ................-2....-2.. 1-3 

DTE/DCE Physical Interface Elements ..................0... 1-3 

Operational Pnases: 2 Acbs-ace 4-2-8 eoe Sb Oa a ee eR SRE So He 1-3 

Failure Detection and Test Loops ..................2.004. 1-3 

Signal -Element-TimMing: sis e604 244454248. ee bGdua cd ok Gb de ees 1-3 

V-Series Interface .........02. 2.20.04 2 ee eee ee Dea cet caties ae en Seep oth a 1-3 

Recommendation X.31 Interface .........0.0..0 0.2.2.0 .20 02.2028. 1-4 

DTE/DCE Physical Interface ..........0.0. 2.2.5.2 eee 1-4 

Operational Phases ..........0..02..0. 0.022002 02 eee ee, 1-4 

WAINICNGNCE: 2454) siine. 4 BS 2 Ee Bae Oe eR Ce ee eee SEES 1-4 

synchronization ................ Bees Se cteewih, Ge ae one Hi csine, SS Be Sad ny. 1-4 

BCCCSS SUCCUS.. “4:2. 6 ted es Bek we Bey oS ee ee eee Ss Rew eee 1-4 

; Chapter 2. Link Access Procedure Across the DTE/DCE interface ..... 2-1 
Scope and Field of Applications ..........0........020..0048. 2-1 
INIPOGUCHONY <2.4+5.a-0s Gk AE eh ee ee or oe I DS Ee Se ee I 2-1 

PERMUINOIOGY: <2t.& &. Baap tee Gee Sao. oe Se ee he a ee Le se SS 2-1 

Media Characteristics: 2.2. 2% sskdcats Ria ee ees Fw ee See 2-2 

Compatibility ........2.. hie Ft Ace hi Re ek SE es ee re 2-2 

LAPB Service Selection ........0... 0.0.0.0 2 eee ee ee ene 2-2 

PANG, SUFUCLUFCS 4 wt uas od wed Wwe a edle, b OeO OeE ee ew eee 2-2 
DEIINGAUOMR . 5.05.03 Stack ty ao Bok Bae & Bk Bo ak DA ee hE ka 2 2-2 

% FIAG-(FSGQUEGNCE * iia) de we aes SSS EMSRS BS Ces Sree s 2-3 
y Address (A) Field ..... ts a sera ee ares eta, ae he oy ae ee ns 2-4 
COMTFOK(GC)PICIG®: ¢. in ee er we & ote BAS A we Ea we ee ee A 2-4 

Information (I) Field 2... 0.20.0... 0.0.0.2 ee ee ee eee 2-4 

Transparency ...........0.0.0. 22.2004 eR cies te Bodh oe Be eee gs 2-5 

Frame Checking Sequence (FCS) Field ..................0.. 2-5 

Order of Bit Transmission ...........0.0 0.000000 2 ee ee eee 2-6 

WiValiG: Tames cc2.0 222% 6 a Fet eee, dh Bae Ba Oe oe ees 2-6 

FYAaING-ADONION. 4-4 “6-2 & dom oP & eds EL a a Oe Se Bal we S&S 2-/ 

interframie THMe-Fill: — 24 654-4, oS wl Se ae Bie See a Se w ee 2-7 

Data Link Channel States ........0...0.0 0.00.00 0 2.0220 2 ee 2-/ 

LAPB Elements of Procedure ..........0 2... 0.2 eee eee eee 2-/ 

DCUDINON: 4: sit, & dee a aan Gk Oe ate ta es sh Sees acs ee 2-/ 

LAPB Control Field Formats and Parameters ................ 2-8 

Functions of the Poll/Final Bit ...................2..220. 2-10 

~ Commands and Responses .............0 00202 ee eee eee 2-11 
| Exception Condition Reporting and Recovery ................ 2-17 
Description of the LAPB Procedure ........... ee ae ee eee ee 2-20 

LAPB Basic and Extended Modes of Operation Bustle ae de Af terse aes ~, 2-20 


Contents Xi 


LAPB Procedure for Addressing ...................000048. 2-21 


LAPB Procedure for Use of the P/F Bit ..............0.00.2.. 2-22 
LAPB Procedure for Data Link Set-Up and Disconnection ......... 2-23 
LAPB Procedures for Information Transfer .................. 2-26 
LAPB Conditions for Data Link Resetting or Re-Initialization ....... 2-32 
LAPB Procedure for Data Link Resetting ................0... 2-32 
List of LAPB System Parameters ..........0...02. 2.000000 2-34 
Multilink Procedure - ( MLP ) (Subscription-time Selectable Option) .... 2-44 
FIGIC OF ANDICAHON. «6 doe. Geko we BES wee Oe ee 2-45 
Multilink Frame Structure 2... 2... 0.0.2.0 002. 2 ee eee en 2-45 
Multilink Control Field Format and Parameters ............... 2-46 
Description of the Multilink Procedure (MLP) ................ 2-51 
List of Multilink System Parameters ...................... 2-58 
LAP Elements of Procedure ............ 2.000 eee wee ee ceae 2-58 
Description of the LAP Procedure ..................0. ere eee 2-58 
Chapter 3. Description of the Packet Layer DTE/DCE Interface ....... 3-1 
LOGICarChaNNelS: <6 5 224.02 Hud eS Be he Ee eae BS Ae oe DS eS 3-2 
SLruCture Of -PACKelS. <0 46:4 62. wd ke bom oU EA wee Be doe ee OS wets 3-2 
PROCCOURCION RESIAM: 4.85% 26 2% a4 Oo ee ee Ee ee Se Ee ae 3-4 
Restate DY INesDIE? se Gs: ed bec en Se eee are. we & Se Se DSc —(3b-4 
ReSstarL OV ING DCE: 4. each Wi Se oo aera Mi ME ee Se Oe eS ae 3-5 
REStQIECOIISION. onde 6S a OE Ow, Re oe Sd Oe ere SB ES 3-5 
Restart :Confirmallon 9. 00 aco Ga sk HK Ee ee ee ee ew ee oe 3-6 
Determining “DTE” or “DCE” Characteristics ................ 3-6 
ErCOr MaANGUAGs 6.5.6) OS. Hie es. r8 e oo OES SOSA BS EAGER RODS 3-7 
DiaGNOStiC PACkel . tnd eae ew. eae ei wg Ae Se oO heer, Ghee eee ie 3-7 
Nonreceipt of window-rotation information ..... sie Oe Wa fe Se Geet erak eae tat gs 3-7 | 
Receipt of erroneous DATA packetS ............0......0.0.. 3-9 
OMGFCONSIGEFALIIONS: 4x2, oe ane m. Sede doe eh eS SE A OE Awe 3-10 
DTE/DTE versus DTE/DCE Operation ..................0..4. 3-10 
Operation Over Circuit-Switched Connections .............:.. 3141 
Chapter 4. Procedures for Virtual Circuit Services .............. 4-1 
Procedure for Virtual Call Service ................ tas Be ead 4-1 
REAGY Dlatee waite uth. & Sos. We: eck eS Boh ee Sw ee a oe es 4-1 
Call Request Packet ......... 0... ee eee eee tee eee 4-1 
Incoming Call Packet .........0....2.2.2.2. 00004 ae ete ue eee 4-2 
Call Accepted Packet ..........0....0.0 0000008000 cee 4-2 
Call Connected Packel. «un ceed ewae bees ea deh Poe ad Fee es 4-3 
Call COMISION® Sng ets Heakt oS eS EEE ESO OS HE eH wees 43 
CIE aviNd DYANG-DTE so, 3 ote deg td Ss, Re Bc & wie Races: Bee 4-3 
Clearing bY (Ne DCE. 4:4 2 des od end we Soe Bees hee eae eS A 4-4 
ClearCOMSION: 2.8.4 dno: toed GS Raw ae Gee BRERA CRS ee 4-5 
UNnsuccessiulCall a3. 3. o.n ee & oe he BESS EME Oe Se Oe 4-5 
Call: FrOgressS: SIGNAIS: ‘4.444 44.44 e em DEERE OK OEE wDE OES 4-5 
Dala IfanSiel Stale fina BA) ell ee oe eee Wee ee ea 4-5 
Procedures for Permanent Virtual Circuit Service ............... 4-5 
Procedures for Data [and Interrupt] Transfer .................. 4-6 
Siaies for Data Transier os 2:4 6 wt ee ce ee a Ee 4-6 
User Data Field Length of Data Packets ................... 4-7 
Delivery Confirmation (D) Bit 2... .......0.0. 0.0.2.2... 002.008. 4-8 
MOLE Dale MAU.” se GG ak: Boke & BAe Ae ew A Met Aw era ee wd 4-9 
Complete Packet Sequence ......... Sean, Gee Ek erent he eee wees ee a 4-10 
RIAU CE MSIE san ncaa. et, “eo a dt <a de oe ae a ee ede eee 4-11 


Architecture Reference 


internupt PFOCCGUFE: 4 wedecee eg es Ree & coer Bd ek ed dew Se SS 
Transit Delay of DATA Packets ........0.0.0.0.0.0.0.... 002.0002. 
Fragmentation and Reassembly of Messages ................ 
Procedures for Flow Control ...........00.0.2020.20.0.0.00.0 02.2040. 
FIOW COMIC) 308 dw en Sie Bee Me Sees Sia Se EWES OR ae 
Throughput Characteristics and Classes ................00.. 
Procedure for Reset .......0.0 0.02. 0. ee ee 
Effects of Clear, Reset and Restart Procedures on the Transfer of Packets 
SNA-to-non SNA CONNeClONS: ..-2 24446444449 See ae oa eee a 
Effects of the Physical and Data Link Layer on the Packet Layer ...... 
General principles 2... 2... 0.00.0. 00 2 ee 
Definition of an out-of-order condition .................204 
Packet Layer Actions on Out-Of-Order Conditions ...........2... 
Packet Layer Actions during Out-Of-Order Conditions ........... 


Chapter 5. Packet Formats ................. Joie easels Bee 
GENCValy ven e.ciacG- 4 wee bee Se Ree Ph ee ge We eS 
General Format Identifier ..........0.. 0.0.02. 2. 2005 ee eee 
Logical Channel Group Number ..........0.... 0820002048. 
LogicalvChannelNUMper save eke a) See eR Baw ee Ae oe 
Packet Type ldentilier ¢.4-2.2 i400 db actog dae eee Se Fe wa ER 
Call Set-Up and Clearing Packets ............0.0.0.2.2. 2.0.00... 
AGGress BIOCK: FORMAL . 46-64 ee 8 ee he Se ee SE 
CALL REQUEST and INCOMING CALL Packets .............. 
CALL ACCEPTED and CALL_ CONNECTED Packets ............ 
CLEAR REQUEST and CLEAR INDICATION Packets ~............ 
DTE and DCE CLEAR CONFIRMATION Packets .............. 
Data [and Interrupt] Packets ...........2.........22-2200.4 
DIE and: DCE DATA aCKelS 4.6. sua me Soe eee as se A a 
DTE and DCE INTERRUPT Packets ...................... 
_ DTE and DCE_INTERRUPT CONFIRMATION Packets .........2... 
Fiow Conirol-and Reset Packets 2.4.5 24 a6 66a beh Go Pe ewe A 
DTE and DCE RECEIVE READY (RR) Packets ................ 
DTE and DCE RECEIVE NOT READY (RNR) Packet ............ 
RESET REQUEST and RESET INDICATION Packets ............. 
DTE and DCE RESET CONFIRMATION Packets ............... 
REStaIGPacKels... 23.4303 44%o 58 $3 oe Ee AS GS ERNE BOERS 
RESTART REQUEST AND RESTART_INDICATION PACKETS ....... 
DTE and DCE_RESTART_ CONFIRMATION Packets ............. 
Diagnostic: Packel | c¢.ccahs. de 8 Grek ed eee ww ED Ra ws SA SS 
DiagNOStic COdG:FIGIG. § $4.4 gsi o BSS Pow oe Oe A Ee OE 
Diagnostic Explanation Field ............... 0.2... 0.2.00048. 
Packets required for optional user facilities ..........0.0.....0.. 
DTE REJECT (REJ) Packet for the Packet Retransmission Facility 
Registration Packets for the On-Line Facility Registration Facility 


Chapter 6. Procedures for Optional User Facilities (Packet Layer) ..... 
On-Line Facility Registration ........... Geet: isthe Seas Rplaeg bal gece eee 

General Procedures for On-Line Facility Registration ........... 

Registration Procedures for Specific Optional User Facilities ...... 
Extended Packet Sequence Numbering .................2..004. 
BI IMOGIICANOR: cece ietto dain te eas & Gk RS Mk Dow & ome Mee Sik niet 
Packet Retransmission .................. Ce oe ee 
Incoming Calls Barred ............ ie a ee eee a ee ee dS, nh eee 
OUIGOING CaliS:BayreG- bok eb Se 2 we Se we ee reeks eae 


Contents 


One-Way Logical Channel Outgoing ........... eka Beene 6-14 


One-Way Logical Channel Incoming ...................000. 6-14 
Non-Standard Default Packet Sizes ...........0.........0004 6-15 
Non-Standard Default Window Sizes .................502000. 6-15 
Default Throughput Classes Assignment .................004 6-15 
Flow Control Parameter Negotiation ...............0.0000. 6-16 
Throughput Class Negotiation .........0. 0.02... 5 0c eee ee eee 6-18 
Closed User Group Related Facilities ...................... 6-19 
Closed User Group ..... ns: ot Gateleiae etude pti Os ins hh Reras omega ee 6-20 
Closed User Group with Outgoing Access ................. 6-21 
Closed User Group with Incoming Access ................. 6-21 
Incoming Calls_Barred_within_a_Closed_User_ Group .......... 6-22 
Outgoing Calls Barred _within_a Closed User Group ........... 6-22 
Closed User_Group Selection .............0 004 ee eee 6-22 
Closed User Group with Outgoing Access Selection .......... 6-23 
Absence of Both CUG Selection Facilities .................. 6-24 
Bilateral Closed User Group Related Facilities ................ 6-26 
Bilateral Closed User Group ................00.2.0 00004 6-27 
Bilateral Closed User Group with Outgoing Access ........... 6-27 
Bilateral Closed User Group Selection ................... 6-27 
Fast SClCCl., uaa Ba B Beh See ee Bs Sh Sle oe Sr gee abe te fee 2. 6-27 
SNA-to-SNA Connections ........... 0000 ee eee ee ees —, 6-27 
SNA-to-non SNA Connections ................-.2. 00000048 6-27 
Fast Selecl sACCCDIANCE: wens deaoeo has adhe davreaeeudcivat an < 6-29 
SNA-to-SNA Connections ................-.2 002.00 020.4 6-29 
SNA-to-non SNA Connections ............2...2.22. 2.28400 6-29 
Reverse Charging. .« 6.4 24.64.44 % 4% & bm Bw oe 2 eee eS eee oe GY 6-29 
Reverse Charging Acceptance ..............2..2.-..202004. 6-30 
Local Charging Prevention ........ * he Beh oe eae ede —. 6-30 
Network _User Identification (NUI) Related Facilities ............. 6-30 
NUPSUDSCHOUON: sie tou. aie oe Oe ee Se ee Ree ew Bee eS Be 6-31 
NUIOVeEMIGeY faa. 6 es ee ee A EE. BG ee eS AS 6-31 
NUIZSCIGCHOM: 4: cte tote wat. & Gb a we ew Le Go BU Gh Boe EE ~5 6-32 
Charging Information .................. ee ee ee ee ee 6-33 
RPOA Related Facilities 2... .. 2. cee ee 6-33 
RPOA.SUDSCHIDUOM. .2.4o% dc teb dt ee ee be ee ea Gs 6-34 
RPOA SCICCHION 0.2 ee oe a ok Se Read S.A ae ee a ot ee 6-34 
PUNT GROUG sy 'eeug vase het igl dh wrk Ae meee ar ceca Sage Stn & ee Bae 6-34 
Call Redirection and Call Deflection Related Facilities ............ 6-35 
Call ReGIFCCHONT sca sient dig Sh ea ee ae eee ee oe ee ee & ee 6-36 
Call Deflection Related Facilities ....................... 6-37 
Call Redirection Or Call Deflection Notification .............. 6-38 
Called Line Address Modified Notification ................0... 6-38 
Transit Delay Selection_and Indication ..................... 6-39 
TOA/NP?I Address: SUDSCINDIION: 4.22055 Gea ee& bee be we ORS 6-40 
Chapter 7. Formats for Facility Fields and Registration Fields ....... f-1 
Senehd! «sed ies ck eee es ea att Web es ee Ge $8 he Gt era Goes 7-1 
Coding of Facility Field in Call Set-up and Clearing Packets ......... 7-4 
Coding of the Facility Code Fields ....................... 7-4 
Coding of the Facility Parameter Fields ................... 7-6 
Coding of the Registration Field of Registration Packets ........... 7-14 
Coding of the Registration Code Fields ....... eee oe hee 7-14 
Coding of Registration Parameter Fields ................... 7-15 


XIV. Architecture Reference 


Appendixes 


Chapter 8. Logical Link Control (LLC) on SNA-to-SNA Connections 
IMEGOOUCHOM: 2. a. 2. 4am Bre ce Reo B6hwe 2 ee et Se Ge Benes OE Soa 
Call User Data (CUD) Field Format ...................... 


Chapter 9. Other System Considerations .................... 
Virtual Circuit Parameter Considerations ..................0.. 
Parameters Applicable to the Entire Interface ................ 
Parameters Applicable to Portions of the Interface ............. 
Parameters Applicable per Call .........0.0..0.0.02..0..0.0.0.04. 
SSCCUNIIV 2.0 GS we dork bee OS oa Oe a oe a te Bee 2 
SNA-to-SNA Connections ..........0.. 20.00.0000 2 eee ee 
SNA-to-non SNA Connections ........0..0 0.000002 eee ee 
Reliability, Availability and Serviceability (RAS) ................ 
PHIOSODINV. “sods Bde Se iat Bie Ro ces ee eS ee oe en eS oe es 
Summary of Error Conditions ...............0 2.2.0.0 0 0.0208. 
General Recommended Actions ............... 000000008. 
Relationship to ISO Open System Interconnection (OSI) ........... 
Protocol Idenuncation . 2.6 «4 oh«.4e240824 4444 62 bee ook ee ER 
PUOUI. ss ob eaten, Stee 2a oe ee dete Bd ae es Ge ee Ee Se ee 


Appendix A. Logical Channel Ranges ...................... 


Appendix B. Packet Layer DTE/DCE Interface State Diagrams ....... 
Symboi definition of ine state diagram .................2....2... 
Order Definition of the State Diagrams ..................... 


Appendix C. Packet Layer DCE Actions ..................... 
INMVOOUCHON sa Scie k, = WH eae a Dora oe S SUP tea ae 


DCE SIate/ACUON Tables: s.2c doi oo bw OES Se ee Ee EE RES 


Appendix D. DCE Time-outs and DTE Time-limits ...........2.2.2.. 
DCE WIMCSOUTS. wat a Ste SH 4 On GR we HB wd we Se eh ee Bt Se 
De PIMC EHMUG: sack er eeaiw anh hosts, Se se he Os ees Wee ae ete Bee 


Appendix E. Network Generated Diagnostic Codes .............. 
Appendix F. On-Line Registration Facility Applicability ............ 


Appendix G. CCITT-Specified DTE Facilities .................. 
BITEOGUICMON. ge see a ys te on ted WA vgs She wat hus wt eas ky a Se he Rie SP ae. ae, ba hee 
Procedures for optional CClTT-Specified DTE facilities .......... 
Coding of the Facility Code Fields ......5. 00045 eee we eee ee. 
Coding of the Facility Parameter Field ...................... 
Calling Address Extension Facility ...................... 
Called Address Extension Facility ...................... 
Quality of Service Negotiation Facilities ................... 
Expedited Data_Negotiation Facility ...................... 


Appendix H. DTE-Generated Diagnostic Codes ................ 
Standard CCITT X.25/ISO-8208 DTE-Generated Codes ............ 
SNA-Specific-DTE Generated Diagnostic Codes ................ 


Contents 


XV 


Appendix |. Description of DTE Packet Layer Actions .......... -.. |1 


WAIPOGUCHION. 4 Goxtog hte ie at as eet is eee ee. be a eae GSS I-1 

Rules and CONVENIONS. 6 4.684224 44.45 42 dca edo 4 4-6 SSaS l-1 
UIE Slates ACuOn Tables: 2.4.4 4<5eiog bad Se ee BE eee ee eee ES |-2 
Appendix J. Physical Services Headers ..................... J-1 
riysical. services (leader POrmalS: 4 a4. 5.5 ad: apareene oe & Be eR ates J-1 
OPeAUMGsWCS: ui .n- 2.5 og ba ckd eet acid eee Ak Ge th mene & eee J-2 
Effects of LAPB Link Resetting ..............0...... pe a athe ets J-3 
Appendix K. SNA-to-non_SNA Architectural Considerations ........ K-1 
Implementation Approach1 ......... 0.0.00 eee eee ene we. Ke 
Implementation Approach2 .................2..2.4. a eee eae K-2 
Implementation Approach3 . 2... 2... ee K-2 
Appendix L. LAPB SLP Finite State Machines ................. L-1 
Introduction to Finite State Machines (FSMs) ............, sie at cd L-1 
LAPB Single Link Procedure ............ 0... 0000 2c eens L-2 

BVGINGS:. digeeea: it ine ee oe ee Bs! eo ee eS Fee ea ak ings a8 tea oe L-2 

COMMAS: << & @ aga ek eke oh ee ee aS hs Rp igh ears cece ect ee Te ut L-3 

RESPONSES: «.2 4-Kek Sk ee Se ea Eee OSS AE Oc & bees L-4 


Appendix M. Description of the Enhanced Logical Link Control - (ELLC) 


PrOCedUures: 244.8 440%-6455 BE Oe EKGE BY RSS SEER CH RSS M-1 
PUNCHON al OVERVIEW: 3 s-s.c0e eee eS i Ee ee hm BE ee Se we ere ee M-1 
PFCWMCOULE. 2 es be tert on ees os A ee be eh Bs M-1 
Link: CONNECHON SeINViICe. 2a 4444404 eee ban hee Se Rowe 2% DSS M-1 
Link Connection Identification .......0.0.0.0..0.00.....0..0..2.008. ~M-2 
Error Detection and Recovery ................ 2.000808 ee M-2 
scope and Field of Application ............0.0 0.0.0.2. 00 20084 M-3 
Link Protocol Data Unit Structure ........0.0............ .. = M-3 
Aadress (A)RIGW - x es e-3k. oar eyo he tee & NS OK Be BAW SB M-4 
ComroltG Field: 2 «6-26 tb BOSS vie hoe Won Pe OAS OM ee KS M-4 
INfORIMMAtOINA BICIGO:  «. g-F-k & eh ew Slave SWS Res @ ee ae eS M-4 
Protocol Data _Unit_Checking Sequence (PDUCS) Field ......... M-4 
Orderof lransSMission! 6<a662¢ 234 624 62446 46S OS Ob SRS ES M-5 
InValGEPDOS. 2.22454 ete ane ce ae Bee se ota 6 8 Be Gees, See M-5 
Link Channel-StateS: .4. ¢4¢2.¢%44 2645 Pe dO oS SOS EW ES es M-5 
Elements of Procedure .........00.020.00. 0000008 eee eee M-5 
LPDU Formats and State Variables ..............0.....00.2. M-5 
Link Commands and Responses ..................2004 .. M-7 
Exception Condition Reporting and Recovery ............... M-11 
Description of the Procedure ............ 0.00. ee ee eens M-15 
Procedure for Addressing ......0.... 000. eee eee ee ee es M-15 
Procedure for Use of the P/F Bit ..........0.......0.00.0. M-15 
Lost Reply Protection .....0...0.0. 2.20.20... 00 eee eee ee ns M-15 
Procedures for Link Set-Up and Disconnection .............. M-16 
LINK DISCONNECCIION: 2.0 sc sdetels sock ane een te Sa Bo Gk ee oe eS M-16 
Procedures for Information Transfer ........0..02.......... M-17 
Link Connection Procedures ..... Shee beech ore bee ee M-22 
Cist-Ol.LLG Parameters. . 2-2: 24466545 4 ow ble & Ee eae GSS M-23 
LPDG Plow Examples: «22227464600 eee Ss oe a Pete LA M-25 
LINK STATION FINITE STATE MACHINES ......... ieee ee Ge M-28 
Chiarh:DESCHPNOR: si. casi eh ave ae ee Ves Bp eh Gee eae M-28 


Link Station States and Actions ..................00005 M-36 


XVI Architecture Reference — 


ra 


Basic Procedure Definitions ................... ee ee M-57 


Appendix N. X.25_ 1980/1984/1988 Compatibility Considerations ...... N-1 
Pir OlG le LIS sa ng a ap Bot ek es eh Saree, Gi Bee? wack Bok ae inca ek tne N-1 
Differences between 1988 and 1984 X%.25 .........0.......002. N-1 
Differences between 1984 and 1980 X.25 ......020.02.2000.0.0..002. N-1 
DATACLINIC VAVER. «p32 + eee eae eS Eb eee Be ee ee a ee S N-2 
Differences between 1988 and 1984X%.25 ................... N-2 
Differences between 1984 and 1980 X.25 .......202.2.2..0202022022. N-2 
PAGKEIOUAVER: <6 a3 4 @ AS. oire & we ou oe Ye eS oe OE a ee N-4 
Differences between 1988 and 1984X%.25 ..............0..0... N-4 
Differences between 1984 and 1980 X.25 .......0.02.20..0...0.4. N-6 
Additional Optional User Facilities ........ mies BO Ere sawn eee N-7 
Expanded CapapiimicS.. og wacko eS a ow SO SO Pe Be aS N-8 
CCiTT-Specified DTE Facilities .........0.0.........0.0.0.00.. N-9 
Appendix O. Description of the BNN_Qualified Logical Link Control - 

(QUEC): ProCceGures: 2 04464084684 «2408S Soh oA GES FER O-1 
PELOGUCHIOM? 2 xeie-aee oh ety ee BAS OE ew Be eet we EO Se ee Rh ee ee O-1 
ElCMeNIS OF PYOCECOUICG: fs doc bak ok eave Gk Bw 2 wa ea OE PS 0-3 

DIQICS” wie wah eb wae eS Sars on Seat ke AG Sh. Ep ee ee we ee ee 0-4 
PrEGICale CONGINON.  ahs6 wane ce ee we ae ae de eR, DO ee, O-5 
EXICIGNOUNTIUIN snide accp: gts ee: oe ae A Sie NE Se eS, ee EE O-6 
GePaCKelFOrnalS: 2542-6 2 sea oa oe Bod 2a Bt Kee EES O-7 
QLLC Commands and Responses .................0.0. 2.20.4 0-9 
PUNCHON-GESCFIDIONS:. *< 4: ek & es BSR ee, boeee be 6 RS 0-13 
Description of the Procedure .....................3.2... QO-14 
Appendix V. Addresses in Call Set-up and Clearing Packets ........ V-1 
Main address and complementary address .................2.4. V-1 
Wiait-GCCreSS fac 6 de ek OG ee eed a Be & Pee ere coe Be ee V-1 
Complementary address ..........0.0.0. 002.000. 2. eee eee V-1 
Address in CALL REQUEST packet ........................ V-2 
Address in INCOMING CALL packets ................ e aeai ade ae V-2 
Address in CALL_ ACCEPTED packets ...................... V-3 
Address in CALL CONNECTED packets ..................... V-3 
Address in CLEAR REQUEST packets ...................... V-4 
Address in CLEAR_INDICATION packets .................... V-4 
Address in CLEAR CONFIRMATION packets .................. V-4 
Addresses in Call Redirection and Call Deflection facilities ......... V-4 
INGOX. 25-8 oi OO Se Ee BY Oe s BERS Bee 8 BS X-1 


Contents XVI 


. Xvi 


Architecture Reference 


ee oR: 


~ X.25 DTE/DCE and DTE/DTE Interface 


X.25 DTE/DCE and DTE/DTE Interface 


Architecture Reference 


aN 


Chapter 1. DTE/DCE Interface Characteristics (Physical Layer) 
> Administrations may offer one or more of the interfaces specified below. The 
> exact use of the relevant points in these specifications is detailed below. 


1.1 CCITT Recommendation X.21 


1.1.1 DTE/DCE Physical Interface Elements 
The DTE/DCE physical interface elements shall be according to §§ 2.1 through 
2.5 of CCITT Recommendation X.21. 


1.1.2 Procedures for Entering Operational Phases 
The procedures for entering operational phases shall be as described in § 5.2 of 
CCITT Recommendation X.21. The data exchanged on circuits T and R when 
the interface is in states 13S, 13R and 13 of Figure A-3/X.21 of CCITT Recom- 
mendation X.21 will be as described in subsequent sections of this specification. 


The not ready states given in § 2.5 of Recommendation X.21 are considered to 
be non-operational states and may be considered by the higher layers to be 
out-of-order states (see “Effects of the Physical and Data Link Layer on the 
Packet Layer” on page 4-23). 
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PHYSICAL LAYER (Layer 1) OPERATIONAL 


Legend: 
'C' signifies c = ON signal 
'c' signifies c = OFF signal 
'T' signifies 1 = ON signal 
'i' signifies i = OFF signal 


Figure 1-1. Physical Layer (Layer 1) Initialization. X.21 Non-Switched 


1.1.3 Failure Detection and Test Loops 
The failure detection principles shall be according to § 2.6 of CCITT Recommen- 
dation X.21. In addition, i = OFF may be signalled due to momentary trans- 
mission failures. Higher layers may delay for several seconds before 
considering the interface to be out-of-order. 


The definitions of test loops and the principles of maintenance testing using the 
test loops are provided in CCITT Recommendation X.150. 


A description of the test loops and the procedures for their use is given in § 7 of 
CCITT Recommendation X.21. 


Automatic activation by a DTE of a Test Loop 2 in the DCE at the remote ter- 
minal is not possible. However, some Administrations may permit the DTE to 
control the equivalent of a Test Loop 2, at the local DSE (Data Switching Equip- 
ment), to verify the operation of the leased line or subscriber line and all or part 
of the DCE or line terminating equipment. Control of the loop, if provided, may 
be either manual or automatic, as described in CCITT Recommendation X.150 
and X.21, respectively. 
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1.1.4 Signal element timing 
Signal element timing shall be in accordance with § 2.6.3 of CCITT Recommen- 
dation X.21. 


1.2 Recommendation X.21_ bis Interface 


1.2.1 DTE/DCE Physical Interface Elements 
The DTE/DCE physical interface elements shall be according to § 1.2 of CCITT 
Recommendation X.21_bis. 


1.2.2 Operational Phases 
When circuit 107 is in the ON condition, and circuits 105, 106, 108 and 109, if 
provided, are in the ON condition, data exchange on circuits 103 and 104 will be 
as described in subsequent sections of this specification. | 


When circuit 107 is in the OFF condition, or any of circuits 105, 106, 108 or 109, if 
provided, are in the OFF condition, this is considered to be in a non-operational 
State, and may be considered by the higher layers to be in an out-of-order state 
(see “Effects of the Physical and Data Link Layer on the Packet Layer” on 

page 4-23). 


1.2.3 Failure Detection and Test Loops 
The failure detection principles, the description of test loops and the procedures 
for their use shall be according to §§ 3.1 through 3.3 of CCITT Recommendation 
X.21_bis. In addition, circuits 106 and 109 may enter the OFF condition due to 
momentary transmission failures. Higher layers may delay for several seconds 
before considering the interface to be out-of-order. 


Automatic activation by a DTE of Test Loop 2 in the DCE at the remote terminal 
is not possible. However, some Administrations may permit the DTE to control 
the equivalent of a Test Loop 2, at the local DSE to verify the operation of the 
leased line or subscriber line and all or part of the DCE or line terminating 
equipment. Control of the loop, if provided, may be either manual or automatic 
as described in CCITT Recommendation X.150 and X.21_bis, respectively. 


1.2.4 Signal Element Timing 


signal element timing shall be in accordance with § 3.4 of CCITT Recommenda- 
tion X.21_ bis. 


1.3 V-Series Interface 


General operation with V-series modems is as described in “Recommendation 
X.21_ bis Interface” above. However, for specific details, particularly related to 
failure detection principles, loop testing, and the use of circuits 107, 109, 113 
and 114, refer to the appropriate CCITT V-series Recommendations. 


The delay between 105-ON and 106-ON (when these circuits are present) will be 


more than 10 ms and less than 1 sec. In addition, circuits 106 or 109 may enter 
the OFF condition due to momentary transmission failures or modem retraining. 
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Higher layers may delay for several seconds before considering the interface to 
be out-of-order. 


.1.4 Recommendation X.31 Interface 


> 1.4.1 DTE/DCE Physical Interface 


> The DTE/DCE physical interface shall coincide with the R reference point 

> between the DTE and the Terminal Adaptor (TA). The purpose of the TA is to 

eS allow the operation of a DTE over an ISDN. The functions of such a TA when 

> accessing a packet switched data transmission service through a semi- 

oa permanent ISDN connection (i.e., a non switched B-channel) are described in § 
> 7 of Recommendation X.31. 

> Notes: 

> 1. This type of access is considered a dedicated access to a public switched 

. data transmission service. Non dedicated {or demand) access to a public 

= switched data transmission service is defined in Recommendations X.32 

> and X.31. 

> 2. The DTE and the TA functions may be implemented in the same piece of 

> equipment in the case of a packet mode terminal TE1 conforming to the 

2 l-series Recommendations. In this case, this Recommendation covers layer 
= 2 and layer 3 operation on a semi-permanent B-channel. 

> 1.4.2 Operational Phases | 


> The operational phases are as described in § 7 of Recommendation X.31. 


> 1.4.3 Maintenance 
> The maintenance shall be made as described tn § 7.6 of Recommendation X.31. 


> 1.4.4 Synchronization 
= The synchronization shall be made as described in § 7 of Recommendation 


> X31. 


1.5 Access Speeds 


IBM SNA X.25 DTEs support one or more of the following CCITT recommended 
data transmission speeds: 


2.4, 4.8, 9.6 or 48.0 Kbit/s. 
Additional data transmission speeds that may be considered by specific IBM 
SNA X.25 DTEs include: 
1.2, 19.2, 56.0 and 64.0 Kbit/s. 


S In order to be compatible with ANS X3.100, ail Packet Switching Data Networks 
S (PSDNs) must support the data signaling rates of 4.8 and 9.6 Kbit/s duplex. 
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Chapter 2. Link Access Procedure Across the DTE/DCE | 
Interface 


Introduction 


Basic functions of the Data Link Layer, link access procedure, for DTEs include: 


e Link initialization - necessary for the DTE to begin communication in a 
known state; 


¢ Flow control - to control the flow of frames between the DTE and the 
other station (DCE or DTE) to ensure that they are not sent more quickly 
than they can be received; 


* Error Detection - provided in two forms, 


1. a cyclic redundancy check (CRC) using a 16-bit polynomial to detect 
mutilated frames, 

2. use of sequence numbers to protect against the loss of entire 
frames; and 


e Error Recovery - which endeavors to insure correct receipt of all frames 
by retransmission of missing or mutilated frames. 
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The Link Access Procedure (LAPB) is described as the Data Link Layer Element 
and is used for data interchange between a DCE and a DTE, or between two 
DTEs, over a single physical circuit, or optionally over multiple physical circuits 
operating in user classes of service 8 to 11 inclusive as indicated in CCITT 
Recommendation X.1. The optional, subscription-time selectable, multiple phys- 
ical circuit operation with LAPB (Known as multilink operation) is required if the 
effects of circuit failures are not to disrupt the Packet Layer operation. 


The single link procedures (SLPs), described in §§ 2.2, 2.3 and 2.4 are used for 
data interchange over a single physical circuit, conforming to the description 
given in Chapter 1, “DTE/DCE Interface Characteristics (Physical Layer),” 
between a DTE and a DCE or between two DTEs. When the optional multilink 
operation is employed, a single link procedure (SLP) is used independently on 
each physical circuit, and the multilink procedure (MLP) described in “Multilink 
Procedure - ( MLP ) (Subscription-time Selectable Option)” on page 2-44 is 
used for data interchange over these multiple parallel LAPB data links. In addi- 
tion, when only a single physical circuit is employed with LAPB, agreements 
may be made with the Administration to use this optional multilink procedure 
over the one LAPB data link. 


2.1.2 Terminology 


The single link procedures {SLPs) use the principles and terminology of the 
High-Level Data Link Control (HDLC) procedures specified by the International _ 
Organization for Standardization (ISO). The multilink procedure (MLP) is based 
on the principles and terminology of the Multilink Control Procedures specified 
by ISO. 
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2.1.3 Media Characteristics 


The transmission facility is duplex. 


2.1.4 Compatibility : 


Station (DCE and DTE) compatibility of operation with the ISO balanced class of 
procedure (Class BA with options 2, 8 and Class BA with options 2, 8, 10) is 
achieved using the LAPB procedures described in §§ 2.3 and 2.4 of this specifi- 
cation. Of these classes, Class BA with options 2, 8 (LAPB modulo 8) is the 
basic service, and is available in all networks. Class BA with options 2, 8, 10 
(LAPB modulo 128) is recognized as an optional, subscription-time selectable, 
extended sequence numbering service that may be available in those networks 
wishing to serve DTE applications having a need for modulo 128 sequence num- 
bering. 


DTE manufacturers and implementers must be aware that the procedure here- 
under described as LAPB modulo 8 will be the only one available in all net- 
works. 


Likewise, a DTE may continue to use the LAP procedure described in §§ 2.2, 2.6 
and 2.7 of CCITT Recommendation X.25 (in those networks supporting such a 
procedure), but for new DTE implementations, LAPB should be preferred. 


Note: 


Other possible applications are being considered by the CCITT, for 
example: 


— two-way alternate, asynchronous response mode; 
— two-way simultaneous, normal response mode; and, 
— two-way alternate, normal response mode. 


2.1.5 LAPB Service Selection 


For those DTE/DCE connections that choose to support both the basic and 
extended LAPB sequence numbering services, the choice of either basic mode 
(modulo 8) or extended mode (modulo 128) may be made at subscription-time. 
The choice of the mode employed for each data link procedure is independent 
of all others and of the choice of mode for the corresponding Packet Layer pro- 
cedures. All choices are matters for agreement for a period of time with the 
Administration. For those DTE/remote DTE connections that support both basic 
(modulo 8) and extended (modulo 128) operation, the choice is made by bilat- 
eral agreement. | 


2.2 Frame Structure 


2.2.1 Delineation 


All transmissions on an SLP are in frames conforming to one of the formats 
shown in Table 1 for basic (modulo 8) operation or, alternatively, one of the 
formats shown in Table 2 for extended (modulo 128) operation. The flag pre- 
ceding the address field is defined as the opening flag. The flag following the 
FCS is defined as the closing flag. | 
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2.2.2 Flag (F) Sequence 


All frames shall start and end with at least one flag sequence consisting of at 
least one 0’ bit followed by six contiguous ‘1’ bits and one ‘0’ bit (01111110). 
The DTE and DCE shall only send complete eight-bit flag sequences when 
sending multiple flag sequences (see § 2.2.11). A single flag sequence may be 
used as both the closing flag for one frame and the opening flag for the next 
frame. 


Note: 


IBM SNA X.25 DTEs transmit and receive bit configurations 
*,,.0111111001111110...° as sequences of multiple flag sequences; and, 
also receive and interpret bit configurations °...011111101111110...’ as 
sequences of multiple flags sequences. 


TABLE 1 — Frame Formats — Basic (Modulo 8) Operation 


Order of Bit 
Transmission 12345678 12345678 12345678 16 to 1 12345678 


F A C 


F 
01111110} 8-bits | 8-bits — 


01111110 


Order of Bit 
Transmission 12345678 12345678 12345678 123....... n 16 to 1 12345678 


FCS 
16—-bits 


Flag 


F 
01111110 


F A C I 
01111110| 8-bits | 8-bits | 


N-Octets! 
\ FCS = frame checking sequence 
1— an Octet is an 8-bit byte. 
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TABLE 2 — Frame Formats — Extended (Modulo 128) Operation 


Order of Bit | 
Transmission 12345678 12345678 1 to * 16 to 1 12345678 


F 


F A C FCS : 
01111110} 8—-bits *¥—bits 16—-bits /01111110 
Order of Bit 


Transmission 12345678 12345678 1to* 123....... n 16 to 1 12345678 
F A C I 
01111110] 8-bits | *-bits 
* 16 for frame formats that contain sequence numbers; 8 for frame 


FCS | 
N-Octets! |16—-bits 
FCS = frame checking sequence 
formats that do not contain sequence numbers. 


F 
01111110 
1— an Octet is an 8-bit byte. 


2.2.3 Address (A) Field 
The A field is a single octet. The address field identifies the intended receiver 
of a command frame and the transmitter of a response frame. The coding of 
the address field is described in § 2.4.2 


2.2.4 Control (C) Field 
For modulo 8 (basic) operation, the control field shall consist of one octet. For 
modulo 128 (extended) operation, the control field shall consist of two octets for 
frame formats that contain sequence numbers, and one octet for frame formats 
that do not contain sequence numbers. The content of this field is described in 
§ 2.3.2 


2.2.9 Information (I) Field | 
_ The information field of a frame, when present, follows the control field (see § 
2.2.4) and precedes the frame check sequence field (see § 2.2.7). 


see §§ 2.3.4.9, 2.5.2, 2.6.4.8, 5, 8 and Appendixes J, M and O for the various 
codings and groupings of bits in the information field as used in this specifica- 
tion. The coding and grouping of bits received from a higher layer are unre- 
stricted, except for requirements that may be imposed by the higher layer itself. 


see §§ 2.3.4.9, 2.4.8.5, 2.6.4.8 and 2.7.7.5 with regard to the maximum informa- 
tion field length. 
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Note: 


Frames containing other than an integral number of octets are ignored 
by IBM SNA X.25 DTEs at the data link layer. 


2.2.6 Transparency 
Transmitting stations examine the frame content between the two flag 
sequences including the address, control, information and FCS fields and insert 
a 0’ bit immediately after all sequences of 5 contiguous ‘1’ bits (including the 
last 5 bits of the FCS) to ensure that a flag sequence is not simulated by data 
on the line. Receiving stations examine the frame content and discard any ‘0’ 
bit which directly follows 5 contiguous ‘1’ bits. 


2.2.4 Frame Checking Sequence (FCS) Field 
The notation used to describe the FCS is based on the property of cyclic codes 
that a code vector such as ‘1000000100001’ can be represented by a polynomial 
P(x) = x12 + x? + 1. The elements of an n-element code word are thus the 
coefficients of a polynomial of order n-1. In this application, these coefficients 
can have the value ‘0’ or ‘1’ and the polynomial operations are performed 
modulo 2. The polynomial representing the content of a frame is generated 
using the first bit received after the frame opening flag as the coefficient of the 
highest order term. ; 


The FCS is a 16-bit sequence. It shall be the ones complement of the sum 
(modulo 2) of: 


1. the remainder of X‘°°’(X15 + X14 + X13 + .. + X* + X + 1 divided 
(modulo 2) by the generator polynomial X16 + X12 + X° + 1, where ‘2’ 
is the number of bits in the frame existing between, but not including, 
the final bit of the opening flag and the first bit of the FCS, excluding 
bits inserted for transparency, and 


2. the remainder of the division (modulo 2) by the generator polynomial. 
X16 + X12 + X° + 1 of the product of X16 by the content of the frame, 
existing between but not including, the final bit of the opening flag and 
the first bit of the FCS, excluding bits inserted for transparency. 


As a typical implementation, at transmitting stations, the initial content of the 
register of the device computing the remainder of the division ts preset to all 
‘{’s and is then modified by division by the generator polynomial (as described 
above) on the address, control and information fields; the ones complement of 
the resulting remainder is transmitted as the 16-bit FCS. 


At receiving stations, the initial content of the register of the device computing 
the remainder is preset to all ‘1’s. The final remainder, after multiplication by 

x16 and then division (modulo 2) by the generator polynomial x16 + x!2 + x? + 
1 of the serial incoming protected bits and the FCS, will be ‘C001110100001111’ 
(X15 through X°, respectively) in the absence of transmission errors. 


Note: 


Examples of transmitted bit patterns by the DCE and the DTE illustrating 
application of the transparency mechanism and the frame check 
sequence to the SABM command and the UA response are given in 
“TRANSMITTED BIT PATTERN EXAMPLES” on page 2-6. 
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2.2.8 Order of Bit Transmission 
Addresses, commands, responses, sequence numbers and information octets 
are transmitted with the low-order bit first (for example the first bit of the 
sequence number that is transmitted has the weight 2°). The FCS shall be 
transmitted to the line commencing with the coefficient of the highest term, 
which is found in bit position 16 of the FCS field (see Tables 1 and 2). 


Note: 
In Tables 1 through 13, bit 1 is defined as the low-order bit. 


2.2.8.1 TRANSMITTED BIT PATTERN EXAMPLES 
‘(Appendix | to CCITT Recommendation X.25 1988: Examples of Data Link 
Layer Transmitted Bit Patterns by the DCE and the DTE). 


Introduction: This section, provided for explanatory purposes, indicates the bit 
patterns that will exist on the physical link for some of the unnumbered frames. 
It is included for the purpose of furthering the understanding of the transpar- 
ency mechanism and the frame check sequence implementation. 


DCE Transmission 


¢ SABM Command Frame with Address = A, P = 1 


First bit transmitted Last bit transmitted 
0111 1110 1100 9000 1111 103100 1101 1010 0011 0111 0111 1110 
Flag Address = A SABM (P=1) Frame Check Sequence’ Flag 
e UA Response Frame with Address = B, F = 1 \ 
First bit transmitted Last bit transmitted 


0111 1110 1000 0000 1100 1110 1101 9001 1110 1010 0111 1110 
Flag Address = B UA(F=1) Frame Check Sequence’ Flag 
DTE Transmission 


¢e SABM Command Frame with Address - B, P = 1 
First bit transmitted Last bit transmitted | 


0111 1110 1000 0000 1111 103100 1101 9111 110711 1011 0111 1110 
Flag Address = B_ SABM(P=1) Frame Check Sequence Flag 


e UA Response Frame with Address = A, F = 1 
First bit transmitted Last bit transmitted 


0111 1110 1100 9000 1100 1110 1100 1100 0010 0110 0111 1110 
Flag Address = A UA(F=1) Frame Check Sequence’ Flag 


3 - Zero inserted for transparency 


2.2.9 Invalid frames 
The definition of an invalid frame is described in § 2.3.5.3. 


a 
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2.2.10 Frame Abortion 


Aborting a frame is performed by transmitting at least seven (7) contiguous ‘1’ 
bits (with no inserted ‘0’s). 


2.2.11 Interframe Time-Fill 


Interframe time-fill is accomplished by transmitting contiguous flags between 
frames, t.e., multiple eight-bit flag sequences (see § 2.2.2). 


2.2.12 Data Link Channel States 


A link channel is defined here as the means for transmission for one direction. 


2.2.12.1 Active Channel State 
The incoming or outgoing channel is defined to be in an active condition when 
the station is receiving or transmitting, respectively, a frame, an abortion 
sequence or interframe time-fill. 


2.2.12.2 Idle Channel State 
The incoming or outgoing channel is defined to be in an idle condition when the 
station is receiving or transmitting, respectively, a continuous ‘1s’ state for a 
period of at least 15 bit times. 


See § 2.3.5.5 for a description of DCE action when an idle condition exists on its 
incoming channel for an excessive period of time. 


IBM SNA X.25 DTEs do not generate Idle Channel state as a normal sequence 
and those that detect the Idle Channel state may consider it either: 


e as an indication that the DCE is not able to support data link set-up; 


e as a simple indication that the DCE has temporarily suspended trans- 
mission; or, 


® as an indication that the data link is in the disconnected phase if a flag 
sequence is not received within at least time Ti. Ti is defined in § 
2.4.8.7. 


‘ Note: 


Upon detection of the idle channel state for at least time T3, DTEs 
should consider the data link to be in the disconnected state. T3 is as 
defined in “DCE Timer T3” on page 2-36. 


2.3 LAPB Elements of Procedure 


2.3.1 Definition 


The LAPB elements of procedure are defined in terms of actions that occur on 
receipt of frames at the DCE or DTE. 


The elements of procedure specified below contain the selection of commands 
_ and responses relevant to the LAPB data link and system configuration 
described in § 2.1. Together §§ 2.2 and 2.3 form the general requirements for 
proper management of the access data link connecting a DCE and an IBM SNA 
X.25 DTE. | 
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2.3.2 LAPB Control Field Formats and Parameters 


2.3.2.1 Control (C) Field Formats 
The C field contains a command or a response, and sequence numbers when 
applicable. 


Three types of C-field formats are used to perform numbered information trans- 
fers (| format), numbered supervisory functions (S format) and unnumbered 
control functions (U format). 


The control field formats for basic {modulo 8) operation are depicted in Table 3. 


TABLE 3 — Control Field Formats — Basic (Modulo 8) Operation 


: 
| I frame te 
ray 
roe eee 


Ns = transmitter send sequence number (bit 2 = low order bit). 
Nr = transmitter receive sequence number (bit 6 = low order bit). 
S = supervisory function bit. 
M = modifier function bit. 
| P/F = poll (P) bit in command frames or final (F) bit in response 
frames (1 = Poll/Final). 
P = Poll bit (1 = Poll). 


Control field bits 8 


The control field formats for extended {modulo 128) operation are depicted in 
Table 4. " 
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TABLE 4 — Control Field Formats — Extended (Modulo 128) Operation 


Control Octet 2 Octet 1 


Field 


Temp 
[seme [ wer 


Single Octet Format M M M P/E M M 


‘i 
S 

M 

X 
wag 


P 


1. 


= send sequence number (bit 2 of octet 1 = low order bit). 
receive sequence number (bit 2 of octet 2 = low order bit). 
Supervisory function bit. 

modifter function bit. 

Reserved and set to 'O'. 

poll (P) bit in command frames or final (F) bit in response 
frames (1 = Poll/Final). 

Poll bit (1 = Poll). 


Information Transfer Format - | 


The | format is used to perform information transfers. The func- 
tions of Ns, Nr and P are independent; t.e., each | frame has an 
Ns, and an Nr which may or may not acknowledge additional | 
frames received by the DCE or DTE, and a P bit that may be set 
to ‘0’ or ‘1’. 


. Supervisory Format - S 


The S format is used to perform data link supervisory control func- 
tions such as acknowledging | frames, requesting retransmission 
of | frames, and requesting temporary suspension of transmission 
of | frames. The functions of Nr and P/F are independent; L.e., 
each supervisory frame has an Nr which may or may not acknowl- 
edge additional | frames received by the DCE or DTE, and a P/F bit 
that may be set to ‘0’ or ‘1’. 


. Unnumbered Format - U 


The U format is used to provide additional data link control func- 
tions. This format contains no sequence numbers, but does 
include a P/F bit that may be set to ‘0’ or ‘1°. The numbered 
frames have the same control field length (one octet) in both basic 
(modulo 8) operation and extended {modulo 128) operation. 
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2.3.2.2 Control Field Parameters 


The various parameters associated with the control field formats are described 


as follows: 


Ne 


Modulus - ‘m’ 


Each | frame is sequentially numbered and may have the value ‘0’ 
through ‘modulus minus one’ (where “modulus” is the modulus of 
the sequence numbers). The modulus equals either ‘8’ or ‘128’ 
and the sequence numbers cycle through the entire range ‘0’ to ‘7 
or ‘0’ to ‘127’, inclusive, respectively. 


. Send State Variable - (Vs) 


Vs denotes the sequence number of the next in-sequence | frame 
to be transmitted. Vs can take on the. value ‘0’ through ‘modulus 
minus one’. The value of Vs is incremented by one with each suc- 
cessive | frame transmission, but cannot exceed the Nr of the last 
received | or S frame by more than the maximum permissible 
number of outstanding | frames (k). The value of ‘k’ is defined in § 
2.4.8.6. 


. Send Sequence Number - (Ns) 


Only | frames contain Ns, the send sequence number of trans- 
mitted frames. At the time that an in-sequence | frame is desig- 
nated for transmission, the value of Ns is set equal to the value of 
the send state variable (Vs). 


. Receive State Variable - (Vr) 


Vr denotes the sequence number of the next in-sequence | frame 
expected to be received. Vr can take on the values ‘0’ through 
‘modulus minus one’. The value of Vr is incremented by one upon 
receipt of each error free, in-sequence | frame whose Ns that is. 
equal to the current value of Vr. 


. Receive Sequence Number - (Nr 


All | frames and S frames contain Nr, the expected sequence 
number of the next received | frame. At the time that a frame of 
the above types is designated for transmission, the value of Nr is 
set equal to the current value of Vr. Nr indicates that the station’ 
transmitting the Nr has correctly received all | frames numbered 
up to and including Nr- 1. 


. Poll/Final Bit - (P/F) 


All frames contain P/F, the Poll/Final bit. In command frames, the 
P/F is referred to as the Poll {P) bit. In response frames, it is 
referred to as the Final (F) bit. 


2.3.3 Functions of the Poll/Final Bit 


‘P = 1' is used by the DCE or DTE to solicit (poll) a response from the DTE or 
DCE/remote DTE, respectively. ‘F = 1’ is used by the DCE or DTE to indicate 
the response frame transmitted by the DTE or DCE, respectively, as a result of 


the soliciting (poll) command. 


Use of the ‘P/F’-bit is described in § 2.4.3. 
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2.3.4 Commands 


and Responses 
For basic (modulo 8) operation, the commands and responses represented in 
Table 5 will be supported by the DCE and the DTE. 


For extended (modulo 128) operation, the commands and responses repres- 
ented in Table 6 will be supported by the DCE and the DTE. 


For purposes of the LAPB procedures, the supervisory function bit encoding ‘11’ 
and those encodings of the modifier function bits in Tables 3 and 4 not identified 
in Tables 5 and 6 are identified as “undefined or not implemented” command 
and response control fields. 


The commands and responses in Tables 5 and 6 are defined in “Information (I) 
Command” through “Frame Reject (FRMR) Response” on page 2-15. 


2.3.4.1 Information (1) Command 


The function of the | command is to transfer across a data link a sequentially 
numbered frame containing an information field. 


| TABLE 5 — Commands and Responses — Basic (Modulo 8) Operation 
8 7 6 


= Disconnect 


DM = Disconnected Mode 
FRMR = Frame Reject 
I = Information 
REJ = Reject 
RNR = Receive Not Ready 
RR = Receive Ready 
SABM = Set Asynchronous Balanced Mode 
UA = Unnumbered Acknowledgement 


M SNA X.25 DTEs transmit Unnumbered commands with 'P = ]' 


iD = Q! 


IB 
and Information command frames with 


Note: 
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TABLE 6 — Commands and Responses ~ Extended ee 128) Operation 


Octet 2 Octet 1 


Piece 


Format 


CMND = Command 
DISC = Disconnect 
DM = Disconnected Mode 
FMT = Format 
FRMR = Frame Reject 
I = Information 
REJ = Reject 
RESP = Response 
RNR = Receive Not Ready 
RR = Receive Ready 
SABM = Set Asynchronous Balanced Mode 
UA = Unnumbered Acknowledgement 


Note: IBM SNA X.25 DTEs: transmit Unnumbered commands with 'P = 1! 
and Information command frames with 'P = Q' 


2.3.4.2 Receive Ready (RR) Command and Response 
The RR supervisory frame is used by the DCE or the DTE to: 


e indicate it is ready to receive an | frame; and, 
e acknowledge previously received | frames numbered up to and 
including ‘Nr - 1. 


An RR frame may be used to indicate the clearance of a busy condition that 
was reported by the earlier transmission of RNR frame by that same station 
(DCE or DTE). In addition to indicating the DCE or DTE status, the RR command 
with ‘P = 1’ may be used by the DCE or DTE to ask for the status of the DTE or 
DCE/remote DTE, respectively. 
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2.3.4.3 Receive Not Ready (RNR) Command and Response 
The RNR supervisory frame is used by the DCE or DTE to indicate a busy condi- 
tion; i.e., temporary inability to accept additional incoming | frames. |-frames 
numbered up to and including ‘Nr- 1° are acknowledged. | frame Nr and subse- 
quent | frames received, if any, are not acknowledged; the acceptance status of 
these I-frames is indicated in subsequent exchanges. 


In addition to indicating the DCE or DTE status, the RNR command with ‘P = 1’ 
may be used by the DCE or DTE to ask for the status of the DTE or DCE/remote 
DTE, respectively. 


Upon receipt of an RNR command or response IBM SNA X.25 DTEs start Query 
Timer, Tn, if it is not running. If Query Timer, Tn, then expires prior to the 
receipt of a UA, RR, REJ or SABM, IBM SNA X.25 DTEs perform the 
retransmission procedure described in § 2.4.8.1 before declaring the data link 
(station) to be inoperative and reporting the condition to a higher layer. 


Note: 


If unacknowledged frames are purged, by the DTE or DCE, as a result of 
sending or receiving an SABM or UA, notification must be given to a 
higher layer so that the DTE/DCE packet layer interface can be restarted 
to protect the integrity of the system when ELLC recovery is not being 
employed. 


2.3.4.4 Reject (REJ) Command and Response 
The REJ supervisory frame is used by the DCE or DTE to request transmission 
of | frames starting with the frame numbered Nr. | frames numbered ‘Nr - 1° 
and below are acknowledged. Additional | frames pending initial transmission 
may be transmitted following the retransmitted | frame(s). 


Only one REJ exception condition for a given direction of information transfer 
may be established at any time. The REJ exception condition is cleared (reset) 
upon receipt of an | frame with an Ns equal to the Nr of the REJ frame. 


An REJ frame may be used to indicate the clearance of a busy condition that 
was reported by the earlier transmission of an RNR frame by that same station 
(DCE or DTE). In addition to indicating the DCE or DTE status, the REJ 
command with ‘P = 1’ may be used by the DCE or DTE to ask for the status of 
the DTE or DCE/remote DTE, respectively. 


2.3.4.5 Set Asynchronous Balanced Mode (SABM/SABME) Command 
The SABM unnumbered command is used to place the addressed DCE or DTE 
in an asynchronous balanced mode (ABM) information transfer phase where all 
command/response control fields will be one octet in length. 


The SABME unnumbered command is used to place the addressed DCE or DTE 
in an asynchronous balanced mode (ABM) information transfer phase where 
numbered command/response (I and S frame) control fields will be two octets 
in length, and unnumbered command/response controi fields will be one octet 
in length. No information field is permitted with the SABM or SABME 
command. The transmission of a SABM/SABME command indicates the clear- 
ance of a busy condition that was reported by the earlier transmission of an 
RNR frame by that same station (DCE or DTE). The DCE or DTE confirms 
acceptance of the SABM or SABME (modulo 8 (basic) operation or modulo 128 
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(extended) operation) command by the transmission at the first opportunity of a 
UA response. Upon acceptance of a this command, the DCE or DTE send state 
variable Vs and receive state variable Vr are set equal to ‘0°. IBM SNA X.25 
DTEs always transmit this command with ‘P = 1°. | 


Previously transmitted | frames that are unacknowledged when this command is 
acted upon remain unacknowledged (see Waiting for Acknowledgement in § 
2.4.5.9). It is the responsibility of a higher layer (e.g., Packet Layer or MLP) to 
recover from the possible loss of the contents (e.g., packets) of such | frames. 


Notes: 


1. For DTE/DCE connections, the mode of operation of a data link (basic 
(modulo 8) or extended (modulo 128)) may be determined at sub- 
scription time. For DTE/DTE connections, the mode of operation of the 
data link (basic (modulo 8)) or extended (({modulo 128)) shall be deter- 
mined by bilateral agreement. 


2. If unacknowledged frames are purged, by the DTE or DCE, as a result of 
sending or receiving an SABM/SABME or U/, notification must be given 
to a higher layer so that the DTE/DCE packet layer interface can be 
restarted to protect the integrity of the system when ELLC recovery is 
not being employed. 


2.3.4.6 Disconnect (DISC) Command | 
The DISC unnumbered command its used to terminate the mode previously set. 
It is used to inform the DCE or DTE receiving the DISC command that the DTE 
or DCE/rernote DTE sending the DISC command is suspending operation. No 
information field is permitted with DISC commands. Prior to taking action on \ 
the DISC command, the DCE or DTE receiving the DISC command confirms the 
acceptance of the DISC command by the transmission of a UA response. The 
DTE or DCE sending the DISC command enters the disconnected phase when it 
receives the acknowledging UA response. IBM SNA X.25 DTEs always transmit 
DISC commands with ‘P = 1’. 


Previously transmitted | frames that are unacknowledged when the DISC 
command is acted upon remain unacknowledged (see Waiting for Acknowledge- 
ment in § 2.4.5.9). It is the responsibility of a higher layer (e.g., Packet Layer or 
MLP) to recover from the possible loss of the contents (e.g., packets) of such | : 
frames. 


Note: 


If unacknowledged frames are purged, by the DTE or DCE, as a result of 
sending or receiving an SABM/SABME or UA, notification must be given 
to a higher layer so that the DTE/DCE or DTE/remote DTE packet layer 
interface can be restarted to protect the integrity of the system. 


2.3.4./ Unnumbered Acknowledgement (UA) Response 
The UA unnumbered response is used by the DCE or DTE to acknowledge 
receipt and acceptance of the mode-setting commands. Received mode-setting 
commands are not acted upon until the UA response is transmitted. The trans- 
mission of a UA response indicates clearance of a busy condition that was 
reported by the earlier transmission of an RNR frame by that same station (DCE 
or DTE). No information field is permitted with the UA response. 


Ye SS 
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2.3.4.8 Disconnected Mode (DM) Response 
The DM unnumbered response is used to report a status where the DCE or DTE 
is logically disconnected from the data link, and is in the disconnected phase. 
The DM response may be sent to indicate that the DCE or DTE has entered the 
disconnected phase without benefit of having received a DISC command, or, if 
sent in response to the reception of a mode-setting command, is sent to inform 
the DTE or DCE that the DCE or DTE, respectively, is still in the disconnected 
phase and cannot act upon the set-mode command. No information field is per- 
mitted with the DM response. 


A DCE or DTE in a disconnected phase will monitor received commands and 
will: 


e react to an SABM/SABME command as described in § 2.4.4 below; and, 


e respond with a DM response with ‘F = 1’ to any other command 
received with ‘P = 1’. 


2.3.4.9 Frame Reject. (FRMR) Response 
The FRMR unnumbered response is used by the DCE or DTE to report an error 
condition not recoverable by retransmission of the identical frame; i.e., at least 
one of the following conditions, which result from the receipt of a valid frame: 


e the receipt of a command or response control field that is undefined or 
not implemented; 


e the receipt of an | frame with an information field which exceeds the 
maximum established length; 


¢ the receipt of an invalid Nr; or, 


e receipt of a frame with an information field which is not permitted or the 
receipt of a supervisory or unnumbered frame with an incorrect length. 


An undefined or not implemented control field is any of the control field 
encodings that are not identified in Tables 5 or 6. 


A valid Nr must be within the range from the lowest send sequence number Ns 
of the still unacknowledged frame(s) to the current DCE or DTE send state vari- 
able, Vs, included (or to the current internal variable ‘x’ if the DCE or DTE is in 
the timer recovery condition as described in § 2.4.5.9). 


An information field which immediately follows the control field, and consists of 
3 or 5 octets (modulo 8 (basic) operation or modulo 128 (extended) operation, 
respectively), is returned with this response and provides the reason for the 
FRMR response. These formats are given in Tables 7 and 8. 
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MR Information Field Format —- Basic (Modulo 8) Operation 


TABLE 7 — FR 


I-field bits 
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Rejected Frame 


Control Field 


With reference to Table 7: 


‘Rejected frame control field’ is the control field of the received frame that 
caused the frame reject. 


‘Vs’ is the current value of Vs at the DCE or DTE reporting the rejection con- 
dition (bit 10 = low-order bit). 
‘C/R’ set to ‘1’ indicates the rejected frame was a response. C/R set to ‘0’ 
indicates the rejected frame was a command. 
‘Vr’ is the current value of Vr at the DCE or DTE reporting the rejection con- 
dition (bit 14 = low-order bit). 
-‘W= 1’ indicates that the control field received and returned in bits 1 
through 8 was considered invalid or not implemented. 


‘X= 1° indicates that the control field received and returned in bits 1 through 
8 was considered invalid because the frame contained an information field 
which is not permitted with this frame or is a supervisory or unnumbered 
frame with incorrect length. ‘W=1’ is required in conjunction with this bit. 


‘Y= 1’ indicates that the information field received exceeded the maximum 
established capacity. 


‘Z=1' indicates that the control field received and returned in bits 1 through 
8 contained an invalid Nr. 


Bits 9 and 21 to 24 shall be set to ‘0’. 


| TABLE 8 — FRMR Information Field Format — Extended (Modulo 128) Operation 


Cl tn 


Rejected Frame 


Control Field 
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With reference to Table 8: 


‘Rejected frame control field’ is the control field of the received frame that 
caused the frame reject. When the rejected frame is an unnumbered frame, 
the control field of the rejected frame is positioned in bit positions 1-8, with 
9-16 set to ‘0’. 


‘Vs’ is the current value of Vs at the DCE or DTE reporting the rejection con- 
dition (bit 18 = low-order bit). 


‘C/R’ set to ‘1’ indicates the rejected frame was a response. C/R set to ‘0’ 
indicates the rejected frame was a command. 


‘Vr’ is the current value of Vr at the DCE or DTE reporting the rejection con- 
dition (bit 26 = low-order bit). 


‘W=1’ indicates that the control field received and returned in bits 1 
through 16 was considered invalid or not implemented. 


‘X= 1’ indicates that the control field received and returned in bits 1 through 
16 was considered invalid because the frame contained an information field 
which is not permitted with this frame or is a supervisory or unnumbered 
frame with incorrect length. ‘W=1’' is required in conjunction with this bit. 


‘Y= 1’ indicates that the information field received exceeded the maximum 
established capacity. 


‘Z=1' indicates that the control field received and returned in bits 1 through 
16 contained an invalid Nr. 


Bits 17 and 37 to 40 shall be set to ‘0’. 


2.3.5 Exception Condition Reporting and Recovery 
The error recavery procedures which are available to effect recovery following 
the detection/occurrence of an exception condition at the Data Link Layer are 
described in “Busy Condition” through “Excessive Idle Channel State Condition 
on Incoming Channel” on page 2-20. Exception conditions described include 
situations which may occur as the result of transmission errors, DCE or DTE 
malfunctions or abnormal operational situations. 


2.3.5.1 Busy Condition 
The busy condition results when a DCE or DTE is temporarily unable to con- 
tinue to receive | frames due to internal constraints (e.g., receive buffering limi- 
tations). In this case an RNR frame is transmitted from the busy DCE or DTE. | 
frames pending transmission may be transmitted from the busy DCE or DTE 
prior to or following the RNR frame. 


An indication that the busy condition has cleared is communicated by the trans- 
mission of a UA (only in response to a SABM/SABME command), RR, REJ, or 
SABM/SABME (modulo 8/modulo 128) frame. 


Upon receipt of an RNR frame from the DCE/remote DTE, the DTE shall discon- 
tinue further transmission of | frames and wait for an indication from the 
DCE/remote DTE that the busy condition has been cleared. If the DTE has | 
frames to send, it shall start a time-out function (Timer Tn) when it receives the 
RNR frame, or if | frames become available to send while in the busy condition, 
the DTE shall start Timer Tn when the first | frame becomes available. If Timer 
Tn runs out before an indication of busy clearance is received, the DTE shall 
send a supervisory command frame with the P bit set to ‘1’ to solicit the status 


Chapter 2. Link Access Procedure Across the DTE/DCE Interface 2-17 


mNnAD Nm AM 


AONAnaAaANANA HAA HA HAD 


A mA MN 


A A A MH 


“f 


of the DCE/remote DTE. The response received with the F bit set to ‘1’ shall 
report the busy/non-busy status of the DCE/remote DTE. The DTE shall repeat- 
edly solicit status in this manner until either a non-busy response is received or 
it is determined that the data link layer should return information regarding the 
status of the information frames to higher layer for subsequent disposition. 


2.3.5.2 Ns Sequence Error 


The information field of all | frames received whose Ns does not equal the 
current value of Vr will be discarded. | 


An Ns sequence error exception condition occurs in the receiver when an | 
frame received contains an Ns which is not equal to the current value of Vr at 
the receiver. The receiver does not acknowledge (increment its Vr) the | frame 
causing the sequence error, or any | frame which may follow, until an | frame 
with Ns equal to Vr is received. 


A DCE or DTE which receives one or more valid | frames having sequence _ 
errors or subsequent supervisory frames (RR, RNR and REJ) shall accept the 
control information contained in the Nr field and the P’ or ‘F’ bit to perform link 
control functions; e.g., to receive acknowledgement of previously transmitted | 
frames and to cause the DCE or DTE to respond (‘P = 1). 


The means specified in §§ 2.3.5.2(2) and 2.3.5.2(3) shall be available for initiating 
the retransmission of lost or errored | frames following the occurrence of an Ns 
sequence error condition. 


1. Checkpoint Recovery 


Checkpoint recovery shall be based on a checkpoint cycle. A check- 
point cycle shall begin with the transmission of a command frame with 
the P bit set to ‘1’ and end either 


e with the receipt of a response frame with ‘F = 1’, or 
e when the reply time-out function (Timer T1) runs out. 


When the station receives the supervisory response frame with the F bit 
set to ‘1’, after having transmitted an Il, RR, RNR or REJ command frame 
with ‘P = 1’, it shall initiate retransmission of all unacknowledged | 
frames with sequence numbers less than the value of the send state 
variable Vs at the time the command frame with ‘P = 1’ was trans- 
mitted. (In the case where the supervisory frame received is a RNR 
response, the station shall first wait for an indication of clearance of the 
busy condition at the DCE/remote DTE before initiating possible 
retransmission.) Retransmission shall start with the lowest numbered 
unacknowledged | frame. | frames shall be retransmitted sequentially. 
New | frames may be transmitted if they become available. Such 
retransmission of | frames is known as checkpoint retransmission. 


When the station detects the necessity for checkpoint retransmission, 
the retransmission shall be started either before or concurrent with 
transmission of the next command frame with ‘P = 1’. 


Note: The DTE and the DCE/remote DTE may each initiate a check- 
pointing cycle independently of the other by the transmission of a 
command frame with ‘P = 1’. Therefore, since two independent check- 
pointing cycles may be in process simultaneously, the station will not 
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initiate checkpoint retransmission upon the receipt of a command frame 
with ‘F = 1’, that is the response to a command frame with ‘P = 1’. 


To prevent duplicate retransmissions, checkpoint retransmission of a 
specific | frame (same Nr in the same numbering cycle) shall be inhib- 
ited for the current checkpoint cycle, if during the checkpoint cycle the 
Station has previously received and acted upon a REJ frame with ‘P = 0 
or1,or‘F = Q. 

Checkpoint retransmission shall also be inhibited if, after sending a 
command frame with ‘P = 1’, an acknowledgment for that frame is 
received before the next checkpoint occurs. 


. REJ Recovery 


The REJ frame is used by a receiving DCE or DTE to initiate a recovery 
(retransmission) following detection of a sequence error. - 


With respect to each direction of transmission on the data link, only one 
“sent REJ” exception condition for a DCE or DTE, to a DTE or 
DCE/remote DTE, is established at atime. A “sent REJ” exception con- 
dition is cleared when the requested | frame is received. 


A DCE or DTE receiving REJ initiates sequential (re-)transmission of | 
frames starting with the | frame indicated by the Nr contained in the REJ 
frame. The retransmitted frames may contain an Nr and a ‘P’ bit that 
are updated from, and therefore different from, the ones contained in 
the originally transmitted | frames. 


. Time-out Recovery 


If, due to a transmission error, a station does not receive (or receives 
and discards) a single | frame or the last | frame(s) in a sequence of | 
frames, it will not detect an Ns sequence error condition and, therefore, 
will not transmit a REJ frame. The DTE or DCE which transmitted the 
unacknowledged | frame(s) shall, following the completion of a system 
specified time-out period (see § 2.4.5.1 and 2.4.5.9 below), take appro- 
priate recovery action to determine at which | frame retransmission 
must begin. The retransmitted frame(s) may contain an Nr and a ‘P’ bit 
that is updated from, and therefore different from, the ones contained in 
the originally transmitted | frame(s). 


IBM SNA X.25 DTEs use the lost reply protection mechanism, described 
in § 2.4.3.1, after a system specified time-out period (see § 2.4.8.2), to 
determine at which | frame to begin retransmission. 


2.3.9.3 Invalid Frame Condition 
Any frame received which is invalid will be discarded, and no action is taken as 
the result of that frame. An invalid frame is defined as one which: 


is not properly bounded by two flags; 


in basic (modulo 8) operation, contains fewer than 32 bits between flags; in 

extended {modulo 128) operation, contains fewer than 40 bits between flags 
of frames that contain sequence numbers or 32 bits between flags of frames 
that do not contain sequence numbers; 


contains a Frame Check Sequence (FCS) error; or, 


contains an address other than ‘A’ or ‘B’ (for single link operation) or other 
than ‘C’ or ‘D’ (for multilink operation). 
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For those DTEs and DCEs that are octet aligned, a detection of non-octet align- 
ment may be made at the Data Link Layer by adding a frame validity check that 
requires the number of bits between the opening flag and the closing flag, 
excluding bits inserted for transparency, to be an integral number of octets in 
length, or the frame is considered invalid. 


Note: 


IBM SNA X.25 DTEs may detect non-octet aligned frames (frames in 
which the number of bits between the opening flag and the closing flag, 
excluding bits inserted for transparency, is other than an integral 
number of octets in length) and consider them invalid at the Data Link 
layer. 


2.9.0.4 Frame Rejection Condition 
A frame rejection condition is established upon the receipt of an error-free 
frame with one of the conditions listed in § 2.3.4.9 above. 


At the local station (DCE or DTE), this frame rejection exception condition is 
reported by an FRMR response for appropriate remote station action. Once a 
siation has established such an exception condition, no additional | frames are 
accepted until the condition is reset by the remote station, except for examina- 
tion of the ‘P’ bit. The FRMR response will be repeated at each opportunity, as 
specified in § 2.4.7.3, until recovery is effected by the remote station, or until the 
local station initiates its own recovery in case the remote station does not 
respond. | 


2.3.5.5 Excessive Idie Channel State Condition on Incoming Channel 
Upon detection of an idle channel state condition {see § 2.2.12.2 above) on the 
incoming channel, the DCE shall wait for a period of T3 (see § 2.4.8.3 below) 
without taking any specific action, waiting for detection of a return to the active 
channel state (i.e., detection of at least one flag sequence). After the period T3, 
the DCE shall notify the higher-layer (e.g., the packet layer or the MLP) of the 
excessive idle channel state condition, but shall not take any action that would 
preclude the DTE from establishing the data link by normal data link set-up pro- 
cedures. 


Note: 


Other actions to be taken by the DCE at the Data Link Layer upon expi- 
ration of period T3 is a subject for further study by the CCITT. 


2.4 


Description of the LAPB Procedure 


The actions, frame transmissions and state transitions that result from events 
occurring in the various states of the X.25 DTE/DCE Data Link Layer interface as 
perceived by IBM SNA X.25 (1988) DTEs are formalized in Appendix L, “LAPB 
SLP Finite State Machines.” 


2.4.1 LAPB Basic and Extended Modes of Operation 
In accordance with the system choice made by the DTE at subscription time, the 
DCE will either support modulo 8 (basic) operation or will support modulo 128 
(extended) operation. Changing from basic operation to extended operation, or 
vice versa, in the DCE requires subscription by the DTE for the desired service, 
and is not supported dynamically. | 
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Table 5 indicates the command and response control field formats used with 
the basic (modulo 8) service. The mode-setting command employed to initialize 
(set-up) or reset the basic mode 


Table 6 indicates the command and response control field formats used with 
the extended (modulo 128) service. The mode-setting command employed to 
initialize (set-up) or reset the extended mode is the SABME command. 


2.4.2 LAPB Procedure for Addressing 


The address field identifies a frame as either a command or a response. A 
command frame contains the address of the DCE or DTE to which the command 
is being sent. A response frame contains the address of the DCE or DTE 
sending the frame. 


In order to allow differentiation between single link operation and the optional 
multilink operation for diagnostic and/or maintenance reasons, different 
address pair encodings are assigned to data links operating with the multilink 
procedure compared to data links operating with the single link procedure. 


Frames containing commands transferred from the DCE to the DTE will contain 
the address ‘A’ for single link operation and address ‘C’ for multilink operation. 


Frames containing responses transferred from the DCE to the DTE will contain 
the address ‘B’ for single link operation and address ‘D’ for multilink operation. 


Frames containing commands transferred from the DTE to the DCE will contain 
the address ‘B’ for single link operation and address ‘D’ for multilink operation. 


Frames containing responses transferred from the DTE to the DCE will contain 
the address ‘A’ for single link operation and address ‘C’ for multilink operation. 


These addresses are coded as follows: 


Address 87654321 


Single Link Operation ‘A! 0090001 1 
HB 090000001 
Multilink Operation ze 00001111 
gO 00°90: 0-91. 2.1 


Note: 


The DCE or DTE will discard all frames received with an address 
other than ‘A’ or ‘B’ {single link operation), or ‘C’ or ‘D’ (multilink 
operation). 


Note: 


For DTE/DTE use {point-to-point non-switched applications), the 
assignment of A/B (single link operation) or C/D (multilink opera- 
tion) addresses shall be made prior to initialization and should be 
capable of being fixed at system generation time. 


The mechanism for ascertaining DTE address allocation in the 
case of point-to-point switched applications for both DTE/DCE 
cases and DTE/DTE cases is a subject for further study. 
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2.4.3 LAPB Procedure for Use of the P/F Bit 
The DCE or DTE receiving an SABM/SABME, DISC, supervisory command 
or | frame with ‘P = 1’ will set ‘F = 1° in the next response frame it trans- 
mits. 


The response frame returned by the DCE or DTE to an SABM/SABME or 
DISC command with ‘P = 1’ will be a UA or DM with ‘F = 1’. The ; 
response frame returned by the DCE or DTE to an I frame with ‘P = 1’, 
received during the information transfer phase, will be an RR, REJ, RNR 
or FRMR response with ‘F = 1°. The response frame returned by the DCE 
or DTE to supervisory command with ‘P=1’, received during the informa- 
tion transfer phase, will be an RR, REJ, RNR or FRMR response with ‘F = 
1°. The response frame returned by the DCE or DTE to an | frame or a 
Supervisory command with ‘P = 1’, received during the disconnected 
phase, will be an DM response with ‘F = 1’. 


The ‘P’ bit shall be used by the DCE or DTE in conjunction with the timer 
recovery condition (see § 2.4.5.9 below). 


The response frame returned by IBM SNA X.25_1988 DTEs to: 


- SABM/SABME or DISC command frame received with ‘P = 1’ will be 
a UA or DM response with ‘F = 1’; | 7 


- | frames received, in the information transfer phase, with ‘P = 1° will 
be an RR, REJ, RNR or FRMR frame with ‘F = 1; 


- supervisory command frames received, in the information transfer 
phase, with ‘P = 1’ will be an RR, REJ, RNR or FRMR frame with ‘F = 
1’; or, 

- | frame or supervisory frame received, during the disconnected 
phase, with ‘P = 1’ will be a DM frame with ‘F = 1’. 


The ‘P’ bit is also used by the IBM SNA X.25 1988 DTEs in conjunction with 
timer recovery conditions as described in § 2.4.5.9. 


Note: 


Other uses of the ‘P’ bit by the DCE is a subject for further study 
by the CCITT. 


2.4.3.1 Lost Reply Protection 
Transmitting stations provide a time-out function to protect against dead-lock 
conditions caused by the loss of responses from the remote station due to 
transmission errors. A timer T1 (or Tp for DTEs) may be started upon trans- 
mission of I-frames or supervisory command frames, or both, during the infor- 
mation transfer phase. Timer T1 (and Tp for DTEs) ts also used during link 
set-up and disconnection as described in §§ 2.4.4.1 and 2.4.4.3, respectively. 


If timer T1 (or Tp for DTEs) expires prior to receipt of an appropriate response 
frame from the remote station, recovery action is initiated by the local station. 
Transmitting stations transmit an appropriate supervisory command frame or 
retransmit the appropriate |-frame with ‘P = 1’ and restart timer T1 (or Tp for 
DTEs). After timer T1 expires N2 times, appropriate recovery action is initiated 
by the DCE. | 
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Upon expiration of timer Tp prior to receipt of an appropriate response with ‘F 
= 1’, IBM SNA X.25 DTEs perform the retransmission procedure described in § 
2.4.8.1 before declaring the data link (station) to be inoperative and reporting 
the condition to a higher layer. 


2.4.4 LAPB Procedure for Data Link Set-Up and Disconnection 


2.4.4.1 Data Link set-up 


The DCE or DTE will indicate that it is able to set-up the data link by transmit- 
ting contiguous flags (active channel state). 


Either the DTE or the DCE/remote DTE may initiate data link set-up. Prior to 
initiation of data link set-up, either the DTE or the DCE/remote DTE may initiate 
data link disconnection (see § 2.4.4.3) for the purpose of insuring that the DTE 
and the DCE/remote DTE are in the same phase (phase synchronization). The 
DCE or DTE may also transmit an unsolicited DM response to request the DTE 
or DCE/remote DTE to initiate data link set-up. 


IBM SNA X.25 DTEs should always take the initiative in the data link layer 
initialization procedure by sending SABM/SABME with ‘P = 1’. The DTE shall 
initiate data link set-up by transmitting an SABM/SABME command to the DCE 
and starting timer T1 in order to determine when too much time has elapsed 
waiting for a reply (see § 2.4.8.1 below). If, upon correct receipt of the 
SABM/SABME command, the DCE determines that it can enter the information 
transfer phase, it will return a UA response to the DTE, will reset its send and 
receive state variables Vs and Vr to zero, and wili consider that the data {ink is 
set-up. If, upon correct receipt of the SABM/SABME command, the DCE deter- 
mines that it cannot enter the information transfer phase, it will return a DM 
response to the DTE as a denial to the data link set-up initialization and con- 
sider that the data link is not set-up. In order to avoid, misinterpretation of the 
DM response received, the DTE shall always send SABM/SABME with ‘P = 1’. 
Otherwise, it is not possible to differentiate a DM response intended as a denial 
to data link set-up from a DM response that is issued in a separate unsolicited 
sense as a request for a mode-setting command (as described in § 2.4.4.4.2). 


The DCE/remote DTE will initiate data link set-up by transmitting an 
SABM/SABME command to the DTE and starting its Timer T1 in order to deter- 
mine when too much time has elapsed waiting for a reply (see § 2.4.8.1 below). 
If on receiving correctly the SABM/SAMBE command, the DTE can enter the 
information transfer phase, it shall return a UA response, set its send and 
receive state variables, Vs and Vr, to ‘0’*, and consider the link set-up. If, on 
receiving correctly the SABM/SABME command, the DTE cannot enter the infor- 
mation transfer phase, it shall return a DM response as a denial to the link 
set-up initialization and consider the link not set up. Upon reception of a UA 
response from the DTE, the DCE will reset its send and receive state variables 
Vs and Vr to zero, will stop its Timer T1, and will consider that the data link is 
set-up. Upon reception of a DM response from the DTE as a denial to the data 
link set-up initialization, the DCE will stop its Timer T1 and will consider that the 
data link is not set-up. 


The DCE or DTE, having sent the SABM/SABME command, will ignore and 
discard any frames except an SABM/SABME or DISC command, or a UA or DM 
response received from the DTE or DCE/remote DTE. The receipt of an 
SABM/SABME or DISC command from the DTE or DCE/remote DTE will result 
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in a collision situation that is resolved per § 2.4.4.5 below. Frames other than 
the UA or DM responses sent in response to a received SABM/SABME 
command will be sent only after the data link is set-up and if no outstanding 
SABM/SABME command exists. | 


After the DCE or DTE sends the SABM/SABME command, if a UA or DM 
response is not received correctly, Timer T1 will run out. The DCE or DTE will 
then resend the SABM/SABME command and will restart Timer T1. After trans- 
mission of the SABM/SABME command N2 times, appropriate higher layer 
recovery action will be initiated. The value of N2 is defined in § 2.4.8.4 below. 


Upon expiration of Timer Tp prior to receipt of an appropriate response with ‘F 
= 1’, IBM SNA X.25 DTEs perform the retransmission procedure described in § 
2.4.8.1 before declaring the data link (station) to be inoperative and reporting 
the condition to a higher layer. 


24.4.2 Information Transfer Phase 
After having transmitted a UA response to the SABM/SABME command or 
having received a UA response to a transmitted SABM/SABME command, the 
DCE or DTE will accept and transmit | and supervisory frames according to the 
procedures described in § 2.4.5 below. 


During the information transfer phase, whenever there has been no activity on 
the data link for a period of time T4, it is strongly recommended that the DTE 
transmit an appropriate supervisory command frame with ‘P = 1’ to query the 
status of the DCE/remote DTE. Receipt of a response with ‘F = 1’ will indicate 
both the existence of a working physical link and the logical status of the 
responding DCE/remote DTE. | 


Upon receipt of an SABM/SABME command, a UA response or a DM response 
with ‘F = 0’, while in the information transfer phase, DTEs will inform the higher 
layer and conform to the resetting procedure described in § 2.4.7.2. 


When receiving an SABM/SABME command while in the information transfer 
phase, DCEs will conform to the data link resetting procedure described in § 
2.4.7.3 below. 


2.4.4.3 Data Link Disconnection 
IBM SNA X.25 DTEs shall initiate a disconnection of ihe data link by transmitting 
a DISC command with ‘P = 1’ to the DCE and starting timer Tp (see 2.4.8.1). 
Upon receipt of a UA or a DM response with ‘F = 1’ from the DCE/remote DTE 
IBM SNA X.25 DTEs stop timer Tp. On correctly receiving a DISC command in 
the information transfer phase, the DCE will send a UA response and enter the 
disconnected phase. On correctly receiving a DISC command in the discon- 
nected phase, the DCE will send a DM response and remain in the discon- 
nected phase. In order to avoid misinterpretation of the DM response received, 
IBM SNA X.25 DTEs always send the DISC command with ‘P = 1°. Otherwise, it 
is not possible to differentiate a DM response intended to indicate that the DCE 
is already in the disconnected phase from a DM response that is issued in a 
separate unsolicited sense as a request for a mode-setting command (as 
described in § 2.4.4.4.2). 


Upon expiration of timer Tp prior to receipt of a UA or DM response with ‘F = 
1’, IBM SNA X.25 DTEs perform the retransmission procedure described in § 
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2.4.8.1 before declaring the data link (station) to be inoperative and reporting 
the condition to a higher layer. 


The DCE/remote DTE will initiate a disconnect of the data link by transmitting a 
DISC command to the DTE and starting timer T1 {see § 2.4.8.1 below). Upon 
reception of a UA response from the DTE, the DCE will stop its timer T1 and will 
enter the disconnected phase. Upon reception of a DM response from the DTE 
as an indication that the DTE was already in the disconnected phase, the DCE 
will stop its Timer T1 and will enter the disconnected phase. 


The DCE or DTE, having sent the DISC command, will ignore and discard any 
frames except an SABM/SABME or DISC command, or a UA or DM response 
received from the DTE or DCE. The receipt of an SABM/SABME or DISC 
command will result in a collision situation that is resolved per § 2.4.4.5 below. 


After the DCE sends the DISC command, if a UA or DM response Is not 
received correctly, Timer T1 will run out in the DCE. The DCE will then resend 
the DISC command and will restart Timer T1. After transmission of the DISC 
command N2 times by the DCE, appropriate higher layer recovery action will be 
initiated. The value of N2 is defined in § 2.4.8.4 below. 


2.4.4.4 Disconnected Phase 

1. A station having received a DISC command and returned a UA 
response, or having received a UA response to a transmitted DISC 
command, is in disconnected phase. 
Stations, in the disconnected phase, may iniiiaie daia link Sei-up. 
While in the disconnected phase, stations react to the receipt of 
SABM/SABME commands as described in § 2.4.4.1 above and 
transmit a DM response to a received DISC command. Upon 
receipt of any other command (defined, or undefined or not imple- 
mented) with ‘P = 1’ while in disconnected phase, the receiving 
Station will transmit a DM response with ‘F = 1°. Other frames 
received while in the disconnected phase will be ignored by the 
receiving station. 


2. When a station enters the disconnected phase after detecting 
error conditions as listed in § 2.4.6 below, or after an internal mal- 
function, it may indicate this by sending a DM response rather 
than a DISC command. In these cases, the station will transmit 
DM with ‘F = 0’ and start Timer T1 (see § 2.4.8.1 below). 


lf Timer T1 runs out before the reception of an SABM/SABME or 
DISC command from the DTE, the station will retransmit the DM 
response and restart Timer T1. After transmission of the DM 
response N2 times, the station will remain in disconnected phase 
and initiate appropriate recovery actions. The value of N2 is 
defined tn § 2.4.8.4 below. 


Alternatively, after an internal malfunction, the DTE may either initiate a data 
link resetting procedure (see § 2.4.7 below) or disconnect the data link (see § 
2.4.4.3 above) prior to initiating a data link set-up procedure (see § 2.4.4.1 
above). 
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2.4.4.5 Collision of Unnumbered Commands 


2.4.4.6 Collision of 


2.4.4.f Collision of 


Collision situations are resolved in the following way: 


e If the sent and received unnumbered commands are the same, 
both stations send a UA response at the earliest possible opportu- 
nity and then enter the indicated phase either: 


1. after receiving the UA response; 
2. after sending the UA response; or, 


3. after timing out waiting for a UA response, having sent a UA 
response. 


In the case of b) above, the station will accept a subsequent UA 
response to the mode-setting command it issued without causing 
a subsequent exception condition (unsolicited UA) if received 
within the time-out interval. 


e If the sent and received unnumbered commands are different, both 
stations enter the disconnected phase and transmit a DM 
response at the earliest possible opportunity. 


DM Response with SABM/SABME or DISC Command 

When a DM response is issued by the DCE/remote DTE or DTE as an unsolic- 
ited response to request the DTE or DCE/remote DTE, respectively, to issue a 
mode-setting command, as described in § 2.4.4.4, a collision between the 
SABM/SABME or DISC command and the unsolicited DM response may occur. 
In order to avoid misinterpretation of the DM response received, IBM SNA X.25 
DTEs always transmit SABM/SABME and DISC commands with ‘P = 1’. 


DM Responses 

A contention situation may occur when both the DCE/remote DTE and the DTE 
issue a DM response to request a mode-setting command. In this case, the 
DTE will issue an SABM/SABME command to resolve the contention situation. 


2.4.5 LAPB Procedures for Information Transfer 


The procedures which apply to the transmission of | frames in each direction of 


- transmission during the information transfer phase are described in “Sending | 


2.4.5.1 Sending | F 


Frames” through “Waiting for Acknowledgement” on page 2-30. 


In the following text, “number one higher” is in reference to a continuously 
repeated sequence series, i.e., ‘7’ is one higher than ‘6’ and ‘0’ is one higher 
than ‘7’ for modulo 8 series, ‘127’ is one higher than 126 and ‘0’ is one higher 
than ‘127 for modulo 128 series. 


rames 

When a station has an | frame to transmit {i.e., an | frame not already trans- 
mitted, or having to be retransmitted as described in § 2.4.5.6 below), it will 
transmit it with an Ns equal to its current value of Vs and an Nr equal to its 
current value of Vr. At the end of transmission of the | frame, the station incre- 
ments Vs by one (1). 


DCEs start timer T1 if it is not running at the instant of transmission of an 
l-frame. 
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IBM SNA X.25 DTEs start timer Tp upon completion of transmission of I-frames 
if it is not already running. IBM SNA X.25 DTEs always send I-frames with P=0. 


If the value of Vs is equal to the last value of Nr received plus ‘k’ (where ‘k’ is 

the maximum number of outstanding I-frames permitted - see § 2.4.8.6 below), 

the station will not transmit any new | frame(s), but may retransmit | frames as 
described in §§ 2.4.5.6 or 2.4.5.9 below. 


In order to insure security of information transfer, the DTE shall not transfer any 
| frame if its Vs is equal the last value of Nr it has received from the 
DCE/remote DTE plus 7 in basic (modulo 8) operation or 127 in extended 
(modulo 128) operation. 


When a station is in the busy condition, it may continue to transmit | frames, 
provided the remote station is not busy. When a station is in the frame 
rejection condition, it will stop transmitting | frames. 


2.4.5.2 Receiving an | Frame 
e When a station is not in a busy condition and receives a valid | 
frame whose send sequence number Ns is equal to its receive 
State variable Vr, the station will accept the information field of 
this frame, increment by one (1) its receive state variable Vr, and 
act as follows: 


— if the station is still not in a busy condition: 


1. If an | frame is available for transmission by the 
Station, it may act as in § 2.4.5.1 above and | 
acknowledge the received | frame by setting Nr 
in the control field of the next transmitted | 
frame to the current value of its receive state 
variable Vr. Alternatively, the station may 
acknowledge the received | frame by transmit- 
ting an RR frame with the Nr equal to the 
current value of Vr. 


2. If nol frame is available for transmission by the 
station, it will transmit an RR frame with Nr 
equal to the current value of Vr. 


— Ifthe station is now in a busy condition, it will transmit an RNR 
frame with Nr equal to the value of Vr (see § 2.4.5.8). 


e When the station is in a busy condition, it may ignore the informa- 
tion field contained in any received | frame(s). 


Note: 
IBM SNA X.25 DTEs treat I-frames received with zero length infor- 


mation fields the same as any other I-frame at the data link layer. 


2.4.5.3 Reception of Invalid Frames 
When a station receives an invalid frame (see § 2.3.5.3), this frame will be dis- 
carded. 
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2.4.5.4 Reception of Out-of-Sequence | Frames 
When a station receives a valid | frame whose send sequence number Ns is 
incorrect, f.e., not equal to the current value of Vr, it will discard the information 
field of the | frame and transmit a REJ frame with an Nr one higher than the Ns 
of the last correctly received | frame. The REJ frame will be a command frame 
with ‘P = 1’ if an acknowledged transfer of the retransmission request is 
required; otherwise the REJ frame may be either a command or a response 
frame. The station will then discard the information field of all | frames 
received until the expected | frame is correctly received. When receiving the 
expected | frame, the station will then acknowledge the | frame as described in 
§ 2.4.5.2 above. The station will use the Nr and ‘P’ bit information in the dis- 
carded | frames as described in § 2.3.5.2 above. 


2.4.5.5 Receiving Acknowledgement 

When correctly receiving an | frame or a Supervisory frame (RR, RNR or RE), 
even in the busy condition, a station will consider the Nr contained in this frame 
as an acknowledgment for all | frames it has transmitted with an Ns up to and 
including the received ‘Nr-1’. The DCE or DTE will stop Timer T1 or Tp when it 
correctly receives an | frame or a supervisory frame with the Nr higher than the 
last received Nr (actually acknowledging some | frame(s), or an REJ frame with 
an Nr equal to the last received Nr. 


If Timer T1 or Tp has been stopped by the receipt of an 1, RR or RNR frame, and 
if there are outstanding | frames still unacknowledged, the station will restart 
Timer T1 or Tp. If Timer T1 or Tp then runs out, the station will follow the 
recovery procedure (see § 2.4.5.9 below) with respect to the unacknowledged | 
frame(s). If Timer T1 or Tp has been stopped by the receipt of an REJ frame, 
the station will follow the retransmission procedures in § 2.4.5.6 below. 


2.4.5.6 Receiving a REJ Frame 
When receiving an REJ frame, a station will set its send state variable Vs equal 
to the Nr of the received REJ control field. It will then transmit the corre- 
sponding | frame as soon as it is available or retransmit it in accordance with 
the procedures described in § 2.4.5.1 above. (Re)transmission will conform to 
the following procedures: 


e if a station is transmitting a supervisory command or response 
when it receives the REJ frame, it will complete that transmission 
before commencing transmission of the requested | frame; 


e if a station is transmitting an unnumbered command or response 
when it receives the REJ frame, it will ignore the request for 
retransmission; 


e if a station is transmitting an | frame when it receives the REJ 
frame, it may abort the | frame transmission and commence 
transmission of the requested I-frame immediately after abortion; 


e if a station is not transmitting any frame when the REJ frame is 
received, it will commence transmission of the requested | frame 
immediately. 


In all cases, if other unacknowledged | frames had already been transmitted fol- 


lowing the one indicated in the REJ frame, then those | frames will be retrans- 
mitted by the station following retransmission of the requested | frame. Other | 
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frames not yet transmitted may be transmitted following the retransmitted | 
frame(s). 


If the REJ frame was received as a command with ‘P = 1’, the station will 
transmit an RR, RNR or REJ response with ‘F = 1’ before transmitting or 
retransmitting the corresponding | frame. 


2.4.5.7 Receiving an RNR Frame 


* Receiving an RNR at the DTE 


After receiving an RNR frame, the DTE will stop transmission or 
retransmission of | frames until an RR or REJ frame is received, or until 
Timer Tp runs out, see § 2.3.5.1. 


* Receiving an RNR at the DCE 


After receiving an RNR frame whose Nr acknowledges all frames previ- 
ously transmitted, the DCE will stop Timer T1 and may then transmit an | 
frame, with the P bit set to 0, whose send sequence number is equal to 
the Nr indicated in the RNR frame, restarting Timer T1 as it does. After 
receiving an RNR frame whose Nr indicates a previously transmitted 
frame, the DCE will not transmit or retransmit any | frame, Timer T1 being 
already running. 


In either case (DTE or DCE), if the Timer (T1 for DCEs or Tn for DTES) runs out 
before receipt of a busy clearance indication, the station (DTE or DCE} wil! 
follow the procedures described in § 2.4.5.9. In any case, the station will not 
transmit any other | frames before receiving an RR or REJ frame or before the 
completion of a data link resetting procedure. 


Alternatively, or if no I-frames are pending transmission, after receiving an RNR 
frame, the station may wait for a period of time (e.g., the length of Timer T1 for 
DCEs or Tn for DTEs) and then transmit a supervisory command frame (RR, 
RNR or REJ) with ‘P = 1° and start Timer T1 (DCEs) or Tp (DTEs), in order to 
determine if there is any change in the receive status of the remote station. The 
remote station shall respond to the ‘P = 1’ with a supervisory response frame 
(RR, RNR or REJ) with ‘F = 1’ indicating either continuance of the busy condi- 
tion (RNR) or clearance of the busy condition (RR or REJ). Upon receipt of the 
response, Timer T1 is stopped. 


e |f the response is the RR or REJ response, the busy condition is 
cleared and the station may transmit | frames beginning with the | 
frame identified by the Nr in the received response frame. 


e If the response is the RNR response, the busy condition still exists, 
and the station will, after a period of time (e.g., the length of Timer 
T1), repeat the enquiry of the remote station receive status. 


If Timer T1 runs out before the status response is received, the enquiry process 
above is repeated. If N2 attempts to get a status response fail (i.e., Timer T1 
runs out N2 times), the DTE will initiate a data link resetting procedure as 
described in § 2.4.7.2. Under the same conditions, the DCE will initiate a data 
link resetting procedure as described in § 2.4.7.2 or will transmit a DM response 
to ask the DTE to initiate a data link set-up procedure as described in § 2.4.4.1 
and enter the disconnected phase. The value of N2 is defined in § 2.4.8.4 
below. 
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If, at any time during the enquiry process, an unsolicited RR or REJ frame is 
received, it will be considered to be an indication of clearance of the busy con- 
dition. Should the unsolicited RR or REJ frame be a command with ‘P = 1’, the 
appropriate response frame with ‘F = 1’ must be transmitted before the station 
may resume transmission of | frames. If Timer T1 is running, the station will 
wait for the non-busy response with ‘F = 1’ or will wait for Timer T1 to run out 
and then may either: 


¢ reinitiate the enquiry process in order to realize a successful P/F 
bit exchange (this option is not allowed in ISO 7776); or, 


e may resume transmission of | frames beginning with the | frame 
identified by the Nr in the received RR or REJ frame. 


2.4.5.8 Station Busy Condition 

When a station enters a busy condition, it will transmit an RNR frame at the 
earliest opportunity. The RNR frame will be a command frame with ‘P = 1’ if 

an acknowledged transfer of the busy condition indication is required; otherwise 
the RNR may be either a command or a response frame. While in the busy 
condition, the station will accept and process S frames, will accept and process 
the contents of the Nr fields of | frames, and will return an RNR response with 
‘F = 1’ if it receives a supervisory command or an | command frame with ‘P = 
1’. To clear the busy condition, the station will transmit either an REJ frame or 
an RR frame, with Nr set to the current value of Vr, depending on whether or 
not it discarded the information field of correctly received | frame(s). 


The REJ frame or the RR frame will be a command frame with ‘P = 1’ if an 
acknowledged transfer of the busy-to-non-busy transition is required; otherwise 
the REJ frame or the RR frame may be either a command or a response frame. 


2.4.5.9 Waiting for Acknowledgement 
The station maintains an internal retransmission count variable (Y) which is set 
to ‘0’ when the station sends a UA response, when the station receives a UA or 
RNR command or response, or when the station correctly receives an | frame 
or supervisory frame with the Nr higher than the last received Nr (actually 
acknowledging some | frame(s)). 


If Timer T1 (or Tp for DTEs) runs out waiting for the acknowledgment for an | | 
frame transmitted, the station will enter the timer recovery condition, add one 
to the internal transmission attempt variable ‘Y’ and set an internal variable ‘X’ 
to the current value of Vs. The DCE will then restart timer T1, set VS equal to 
the last value of Nr received and retransmit the corresponding I-frame with ‘P 
= 1’ or transmit an appropriate supervisory command frame (RR, RNR or REJ) 
with ‘P = 1°. IBM SNA X.25 DTEs restart Timer Tp, set Vs equal to the last 
value of Nr received and transmit an appropriate supervisory command frame 
(RR, RNR or REJ) with ‘P = 1’. To be in compliance with ISO 7776, DTEs must 
transmit an appropriate supervisory command with ‘P = 17, not retransmit the 
corresponding I-frame. 


The timer recovery condition is cleared when the station receives a valid Super- 
visoiy frame with ‘F = 1. 


If, while in the timer recovery condition, the station correctly receives a supervi- 


sory frame with ‘F = 1’ and with the Nr within the range from its current Vs to 
*X’ included, it will clear the timer recovery condition (including stopping Timer 
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T1 or Tp) and set Vs equal to the value of the received Nr, and may then 
resume with | frame transmission or retransmission as appropriate. 


If, while in the timer recovery condition, the station correctly receives a supervi- 
sory response frame ‘F = OQ’ or an | frame with the ‘P/F’ bit set to ‘0’ or ‘1’ and 
with a valid Nr (see § 2.3.4.9), it will not clear the timer recovery condition. The 
value of the received Nr may be used to update Vs. 


lf the received supervisory frame with the ‘P/F’ bit set to ‘0’ is an REJd frame 
with a valid Nr, the DCE may either immediately initiate (re)transmission from 
the value of the send state variable Vs, or it may ignore the request for 
retransmission and wait until the supervisory frame with ‘F = 1’ is received 
before initiating (re)transmission of frames from the value identified in the Nr 
field of the supervisory frame with ‘F = 1’. In the case of immediate 
retransmission, in order to prevent duplicate retransmissions following clear- 
ance of the timer recovery condition, the DCE shall inhibit the retransmission of 
a specific | frame (same Nr) in the same numbering cycle if the DCE has 
retransmitted that | frame as the result of a received REJ frame with the ‘P/F’ 


bit set to ‘0’. 


If, while in the timer recovery condition, the DCE receives a REJ command with 
‘P = 1’, the DCE will respond immediately with an appropriate Supervisory 
response with ‘F = 1’. The DCE may then use the value of the Nr in the REJ 
command to update Vs, and may either immediately begin (re)transmission 
from the value of Nr indicated in the REJ frame or ignore the request for 
retransmission and wait until the sunervisory frame with ‘F = 1’ is received 
before initiating (re)transmission of | frames from the value indicated in the Nr 
field of the supervisory frame with ‘F = 1’. 


In the DCE: If. Timer T1 runs out in the timer recovery condition, and nolorsS 
frame with ‘F = 0’ and with a valid Nr has been received, or no REJ command 
with ‘P = 1° and with a valid Nr has been received, the DCE will add one to its 
transmission attempt variable, restart Timer T1, and either retransmit the | 
frame with ‘P = 1° or transmit an appropriate supervisory command with ‘P = 
As 


In the DTE {according to ISO 7776): If Timer Tp runs out before a supervisory 
response frame with ‘F = 1’ is received, the DTE will retransmit an appropriate 
supervisory command frame (RR, RNR or REJ) with ‘P = 1’. 


If the transmission attempt variable (Y) is equal to N2 {or Np for DTEs), the 
Station will initiate a data link resetting procedure as described in § 2.4.7.2 or 
the DCE will transmit a DM response to ask the DTE to initiate a data link set-up 
procedure as described in § 2.4.4.1 above and enter the disconnected phase. 

N2 (and Np for DTEs) are system parameters (see § 2.4.8.4). 


Note: 


Although the DCE may implement the internal variable ‘X’, other 
mechanisms exist that achieve identical functions. 
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+ IBM SNA X.25 DTEs maintain separate retry counts for Information and Supervi- 
oF sory frames: 


1. a ‘transmission count’ variable - which is: 


e initialized upon completion of the data link set-up procedure and 
upon receipt of an Nr acknowledging some I-frame(s): and 

e incremented up to N2 times upon successive expirations of Reply 
Timer, Tp, while in the OPENED state, and 


2. a ‘poll count’ variable - which ts: 


e jnitialized upon expiration of Reply Timer, Tp, while in the OPENED 
State; and | 

e incremented up to N2 times upon successive expirations of Reply 
Timer, Tp, while in the CHECKPOINTING state. 


In the event that either the ‘transmission count’ or the ‘poll count’ variable 
exceeds the retry limit, N2, IBM SNA X.25 DTEs report the access data link 
failure to a higher layer. 


2.4.6 LAPB Conditions for Data Link Resetting or Re-Initialization 


s 2.4.6.1 Sending Frame Reject 

S When a station (DTE or DCE) receives, during the information transfer phase, a 
frame which is not invalid (see § 2.3.5.3) with one of the conditions listed in § 
2.3.4.9 above, it will request the remote station (DCE or DTE) to initiate a data 

S link resetting procedure by transmitting a FRMR response as described in § 

S 2.4.7.3. (A DTE will also report the error condition to a higher layer.) 


s 2.4.6.2 Receiving Frame Reject 

When a station receives, during the information transfer phase, an FRMR 
+ response, it will initiate the data link resetting procedure as described in § 
i 2.4.7.2. {A DTE will also report the error condition to a higher layer.) 


2.4.6.3 Unsolicited UA or ‘F = 1’ 


When a station receives, during the information transfer phase, a UA response, 


4 or an unsolicited response with ‘F = 1’, it will initiate the data link resetting 
of procedure as described tn § 2.4.7.2. (A DTE will also report the error condition 
“F to a higher layer.) 


2.4.6.4 Unsolicited DM 


a When a station receives, during the information transfer phase, a DM response, 
“hy it will initiate the data link set-up (initialization) procedure as described in § 
+e 2.4.4.1. (A DTE will also report the error condition to a higher layer.) 


2.4. LAPB Procedure for Data Link Resetting 


24.7.1 Definition 


i The data link resetting procedure, which is used to initialize both directions of 
=“ information transfer according to the procedure described below, applies only 
1 during information transfer phase. 


Either the DTE or the DCE/remote DTE may initiate the data link resetting proce- 
dure. The data link resetting procedure indicates a clearance of any existing 
DCE and/or DTE busy condition. 
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s 2.4.7.2 Link reset 


The station (DTE or DCE/remote DTE) shall initiate a data link resetting by 
transmitting an SABM/SABME command to the remote station (DCE/remote 
DTE or DTE respectively) and starting its Timer T1. If, upon correct receipt of 
the SABM/SABME command, the remote station (DCE/remoie DTE or DTE) 
determines that it can continue in the information transfer phase, it will return a 
UA response, reset its send and receive state variables, Vs and Vr, to ‘0’, and 
remain in the information transfer phase. If, upon correct receipt of the 
SABM/SABME command, the remote station determines that it cannot remain 
in the information transfer phase, it will return a DM response denying the 
resetting request and enter the disconnected phase. 


Upon reception of a UA response, the station will reset its send and receive 
state variables Vs and Vr to ‘0’, stop its Timer T1, and remain in the information 
transfer phase. Upon reception of a DM response, denying the data link reset- 
ting request, the station will stop its Timer T1 and enter the disconnected 
phase. 


The station, having sent an SABM/SABME command, will ignore and discard 
any frames received from the remote station except an SABM/SABME or DISC 
command, or a UA or DM response. The receipt of an SABM/SABME or DISC 
command from the remote station will result in a collision situation that is 
resolved per § 2.4.4.5 above. Frames, other than a UA or DM response sent in 
response to a received SABM/SABME or DISC command, will be sent only after 
the data link is reset and if no outstanding SABM/SABME command exists. 


After the station sends the SABM/SABME command, if a UA or DM response is 
not received correctly, Timer T1 will run out in the sending station. The station 
will then resend the SABM/SABME command and will restart Timer T1. Ajter 
N2 attempts to. reset the data link, the station will initiate appropriate higher 
layer recovery action and will enter the disconnected phase. The value of N2 is 
defined in § 2.4.8.4 below. 


s 2.4.7.3 Request for Link Reset 


A station (DCE or DTE) may ask the remote station to reset the data link by 
transmitting an FRMR response (see § 2.4.6.1 above). After transmitting an 
FRMR response, the station will enter the frame rejection condition. 


The frame rejection condition is cleared when the station receives an 
SABM/SABME command, a DISC command, a FRMR response, or a DM 
response; or transmits an SABM/SABME command, a DISC command, or a DM 
response. Other commands received while in the frame rejection condition will 
cause the station to retransmit the FRMR response with the same information 
field as originally transmitted. 


The station will start Timer T1 on transmission of the FRMR response. If Timer 
T41 runs out before the frame rejection condition is cleared, the station shall 
retransmit the FRMR response, and restart T1. If timer T1 is not started, or 
after N2 attempts (timeouts) to get the remote station to reset the data link, the 
station will reset the data link itself as described in § 2.4.7.2 above. The value 
of N2 is defined in § 2.4.8.4 below. 


In the frame rejection condition, | frames and supervisory frames will not be 


transmitted by the station. Also, received | frames and supervisory frames will 
be discarded by the station except for the observance of a ‘P = 1°. When an 
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additional FRMR response must be transmitted by the station as a result of the 
receipt of a ‘P = 1 while Timer T1 is running, Timer T1 will continue to run. 
Upon receipt of an FRMR response (even during a frame rejection condition), 


the station will initiate a resetting procedure by transmitting an SABM/SABME 
command as described in § 2.4.7.2 above, or will transmit a DM response to ask 
the remote station to initiate the data link set-up procedure as described in § 
2.4.4.1 and enter the disconnected phase. 


2.4.8 List of LAPB System Parameters 


The DCE and DTE system parameters are as follows: 


2.4.8.1 Time-Outs and Time-Limits 
IBM SNA X.25 DTE timers are referenced using the terms: 


start timer - meaning causing the timer to be switched on and begin 
counting down to zero from the time parameter value; and 


reset timer - meaning causing the timer to be stopped immediately and 
switched off. 
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e DTE Timer, Tp (DCE Timer, T1) 


DTE Reply Timer, Tp, is used to prevent dead-lock conditions and 
to detect transmission errors due to faulty data link channel opera- 
tion. The value of the DTE Reply Timer Tp system parameter may 
be different than the value of the DCE/remote DTE Timer T1 

system parameter. These values shall be made known to both the 
DTE and the DCE/remote DTE and agreed to for a period of time 
by both the DTE and the DCE/remote DTE. 


The period of Timer Tp, at the end of which retransmission of a 
frame may be initiated (see §§ 2.4.4 and 2.4.5 above), shall take 
into account whether Tp is started at the beginning or at the end 
of frame transmission. 


The proper operation of the procedure requires that the transmit- 
ter’s (DCE/remote DTE or DTE) Timer Ti or Tp be greater than the 
maximum time between transmission of a frame (SABM/SABME, 
DISC, | or Supervisory command or DM or FRMR response) and 
the reception of the corresponding frame returned as an answer to 
that frame (UA, DM or acknowledging frame’. Therefore, the 
receiver (DCE/remote DTE or DTE) should not delay the response 
or acknowledging frame returned to one of the above frames by 
more than a value T2, where T2 is a system parameter. 


The DCE will not delay response or acknowledging frames 
returned to one of the above DTE frames by more than T2. 


DTE Time-Out Function, (Ft) 


The duration of the time-out function (Ft) is: 


Ft = (TpeNptTd)eNd 
where: 


The duration of DTE Reply Timer, Tp, is a function of the 
time allowed by DTEs between the transmission of 
command frames and receipt of the corresponding 
acknowledging frame. | 


Upon expiration of Reply Timer Tp, DTEs retransmit the 
command with ‘P = 1’ and restart Reply Timer Tp. 


Np >'1' is the maximum number of transmissions and 
retransmissions of a frame following the expiration of 
Reply Time, Tp. 


The duration of Delay Timer, Td, is typically many times 
greater than the duration of Reply Timer, Tp, and is the 
time to be delayed between consecutive repetitions of 
TpeNp. 


Nd > ‘1’ is the maximum number of repetitions of 
Tp*®Np + Td to be performed before declaring the data link 
Station to be inoperative. 


Although the duration of Delay Timer, Td, may be defined as zero, 
experience has shown that when Td=‘0’ and Nd=‘1’ are used, 
links are often declared inoperative prematurely, causing unneces- 
sary session outages and user dissatisfaction. 


It is, therefore, highly recommended that Tp, Np, Td and Nd have 
default values that can be overridden by customers as experience 
indicates. 


IBM SNA X.25 DTEs start Reply Timer, Tp, upon completion of 
transmission of | frames and supervisory command frames. 


2.4.8.2 Response Timer, T2 
The value of the DTE parameter T2 may be different than the value of the 
DCE/remote DTE parameter T2. These values shall be made known to both the 
DTE and the DCE/remote DTE, and agreed to for a period of time by both the _ 
DTE and the DCE/remote DTE. 


The period of parameter T2 is the amount of time available at the DCE/remote 
DTE or DTE before transmission of the acknowledging frame must be initiated in 
order to ensure its receipt by the DTE or DCE/remote DTE, respectively, prior to 
Timer T1 or Tp running out at the DTE or DCE/remote DTE. T2 Its less than T1. 


To insure that responses to received frames are transmitted within the required 
time limit, IBM SNA X.25 DTEs may use Response Timer T2 when immediate 
transmission of a required response is not deemed desirable. 


Note: 


The period of parameter T2 shall take into account the following timing 
factors: 


e the transmission time of the acknowledging frame, 

e the propagation time over the access data link, 

e the stated processing time at the DCE and the DTE, and 

e the time to complete the transmission of the frame(s) in the DCE or 
DTE transmit queue that are neither displaceable or modifiable in 
an orderly manner. 


Given a value for Timer T1 for the DTE or DCE, the value of parameter 
T2 at the DCE or DTE, respectively, must be no larger than T1 minus 2 
times the propagation time over the access data link, minus the frame 
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processing time of the acknowledging frame by the DCE or DTE, respec- 
tively. 


2.4.8.3 DCE Timer T3 
The DCE shall support a Timer T3 system parameter, the value of which shall 


be made known to the DTE. Timer T3 is optional to the DTE. 


The period of Timer T3, at the end of which an indication of an observed exces- 
sively long idle channel state condition is passed to the Packet Layer, shall be 
sufficiently greater than the period of the DCE Timer 11 (i.e., T3 greater than T1) 
so that the expiration of T3 provides the desired level of assurance that the 
data link channel is in a non-active, non-operational state, and is in need of 
data link set-up before normal data link operation can resume. 


2.4.8.4 Maximum Number of Attempts to Complete a Transmission, N2 
The value of the DTE N2 system parameter may be different than the value of 
the DCE/remote DTE N2 system parameter. These values shall be made known 
to both the DTE and the DCE/remote DTE, and agreed to for a period of time by 
both. 


The value of N2 shall indicate the maximum number of attempts made by the 
DCE/remote DTE or DTE to complete the successful transmission of a frame to 
the DTE or DCE/remote DTE, respectively. It is used to initialize or establish 
limits for the transmission of both I-frames and supervisory or unnumbered 
command frames with ‘P = 1. 


2.4.8.5 Maximum Number of Bits in an | frame, N1 
The value of the DTE N1 system parameter may be different than the value of 
the DCE/remote DTE N1 system parameter. These values shall be made known 
to both the DTE and the DCE/remote DTE, and agreed to for a period of time by 
both. 


The value of N1 shall indicate the maximum number of bits in an | frame 
(excluding flags and ‘0’ bits inserted for transparency) that the station DTE is 
willing to accept from the remote station. 


In order to allow for universal operation, a DTE will support a value of DTE N1 
which is not less than 1080 bits, (135 octets). DTEs should be aware that the 
network may transmit longer packets (see § 5.2), that may result in a data link 
layer problem. 


All networks shall offer to a DTE which requires it, a value of DCE N1 which is 
greater than or equal to 2072 bits (259 octets) plus the length of the address, 
control and FCS fields at the DTE/DCE interface, and greater than or equal to 
the maximum length of the DATA packets which may cross the DTE/DCE inter- 
face plus the length of the address, control and FCS field at the DTE/DCE inter- 
face. 


The following provides a description of how the values given for the parameter 
N1 are derived. | 


e DTE N1 - For universal operation, a DTE must be capable of accepting at 
least the largest packet that can be transmitted across a DTE/DCE interface 
when no options apply. This implies that the DTE may choose not to 
support, for example, any optional facilities for universal operations, but 
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must support, for example, a DATA packet using the standard default 
packet size. Therefore, the determining factor for the maximum value of N‘1 
that a DTE must.support is the standard default packet size of a DATA 
packet rather than the size of a call setup packet. Thus, for universal oper- 
ation a DTE should support a value of DTE N1 which is not less than 135 
octets, derived as shown in the following table. 


TABLE 8.1 Derivation of minimum value of Nl for OTE 


name of the field 


| Packet Header (Layer poceencon = aaa 


User Data (Layer 3) 


Address (Layer 2) 


139 


Note - A DTE will need to support larger values of N1 when optional facill- 
ties will apply. 


DCE N1 - When the maximum length of the data field of a DATA packet sup- 


_ ported is less than or equal to the standard default value of 128 octets, the 


determining factor (for the value of DCE N1) is the CLEAR_REQUEST packet 
rather than the DATA packet. Therefore, the network shall offer to a DTE, a 
value of DCE N1 which is not less than 263 or 264 octets, derived as shown 
in the following table. 
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name of the field | length of the field (octets) 


Header (Layer 3) 


Clearing Cause (Layer 3) 


Diagnostic Code (Layer 3) 
DTE Address Length (Layer 3) 


DTE Address(es) (Layer 3) 


— 
aa wn b> po re WwW 


Facility Length (Layer 3) 
Facilities (Layer 3) 109 


Clear User Data (Layer 3) | 128 


Layer 3 Total | 299 


| 


Address (Layer 2) 
Control (Layer 2) Pore? 


Multilink Procedure ore 


TOTAL 


263; or 204* or 269" or-266" > 


“If Layer 2 Modulo 128 operation is supported. 


** Multilink Procedures (MLP) are supported. 


When the maximum length of the user data field of a DATA packet sup- 


ported is greater than the standard default value of 128 octets, the deter- 
mining factor (for the value of DCE N1) is the DATA packet rather than the 
CLEAR REQUEST packet. Therefore, the network shall offer to a DTE, a 


value of DCE N1 which ts greater than or equal to: 


the maximum length of the DATA packet + 
the length of the address field (Layer 2) + 
the length of the control field (Layer 2) + 


the length of the FCS field (Layer 2). 
GENERAL DCE N1 CALCULATIONS 


The following table indicates the value of DCE N1 for each possible case. 
The table shows for each case whether 


aaa Layer 2 Modulo 128 is used, 


Multilink Procedures are used, 


— Layer 3 Modulo 128 is used, and/or 
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— the maximum length of the data field (p) in a DATA packet is greater 
than or equal to 256 octets. 


Table 8.3 Various cases and corresponding minimum Nl values for a DCE 


Layer 3 DCE Nl 
Mod 128] p=256 (octets) 


259 + Qe + ORK 


259 + A* +] eee 
259 + g* +]**** + OnKKKK 


X | p + 3** + [eee 4 Qe 


X p + 3** + [***F + qx +O RKKEK 
259 + 4* + [eee 


ann 
pee 


* The number of octets for Modulo 8 Layer 2 frame fields. 
** The number of octets for Layer 3 packet header fields. 
*** Additional octet for Layer 3 Modulo 128 operations. 
**** Additional octet for Layer 2 Modulo 128 operations. 
***** Additional octets for MLP support. 
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2.4.8.6 Maximum Number of Outstanding | frames, K 
S In the case of DTE/DCE operation, the value of the DTE K system parameter 
Shall be the same as the value of the DCE K system parameter. This value 
Shall be agreed to for a period of time by both the DTE and the DCE. In the 
case of DTE/DTE operation, the value of the DIE K system parameter may be 
different from the value of the remote DTE K system parameter. These values 
will be agreed to for a period of time by both the DTE and the remote DTE. 


ww WF WM | 


The value of K shall indicate the maximum number of sequentially numbered | 
frames that the DTE or DCE may have outstanding (i.e., unacknowledged) at any 
given time. The value of K shall never exceed seven (7) for modulo 8 (basic) 
operation, or one hundred twenty seven for modulo 128 (extended) operation. 
§ All networks (DCEs) and all DTEs shall support a value of seven. Other values 
S may also be supported. | 


+ 2.4.8.7 DTE idle Timer, Ti (Called T4 in ISO 7776) 
The purpose of the Idle Timer, which has a value of Ti, ts to assist in preventing 
the persistence of an idle condition on a data link channel. | 


This is the period of time that a DTE may allow the idle channel state to exist 
before considering it to be in the disconnected phase {out-of-order state). Typi- 
cally, the duration of Idle Timer, Ti, should be many times greater than the 
duration of Reply Timer, Tp. 


2.4.8.8 Query Timer, Tn 
This timer is used to detect excessive periods of data link inactivity. The period 
S of Query Timer, Tn, is the time following receipt of a remote station busy indi- 
S cation after which a DTE initiates a ‘P/F cycle’ to assure the connection is oper- 
able. Query Timer, Tn, is typically equivalent to Reply Timer, Tp. 
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Legend: 


— Receive Data Link Channel Active 
Receive Data Link Channel Idle 

— Transmit Data Link Channel Active 
Transmit Data Link Channel Idle 


| 
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Figure 2-1. Data Link Layer (Layer 2) LAPB_SLP. Activation 
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Figure 2-2. Data Link Layer (Layer 2) LAPB_SLP. Initialization/Disconnection 
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Figure 2-3. Data Link Layer (Layer 2) LAPB_SLP. Resetting 


Notes with reference to Figure 2-3: 


1. Transition is not allowed by some PSDN certification procedures. On 
those PSDNs, DTEs respond UA(F =0|1) to received SABM commands 
and then initiate the disconnection procedure to achieve this state. 


2. In the DCE Rejection state, DTEs are responsible for restoring the data 
link to normal operation by initiating either the LAPB initialization pro- 
cedure or the LAPB disconnection procedure. 
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Multilink Procedure - ( MLP ) (Subscription-time Selectable 


The Multilink procedure (MLP) exists as an added upper sublayer of the Data 
Link Layer, operating between the Packet Layer and more than one single data 
link protocol function (SLP) in the Data Link Layer (see figure below). 


A multilink procedure (MLP) performs the functions of accepting packets from 
the Packet Layer, distributing those packets across the available SLPs for trans- 
mission, and resequencing the packets received from the SLPs for delivery to 
the Packet Layer. 


| Physical Layer | Data Link Layer | Packet Layer 


Entity l 


Entity 2 


| 

| | entity N 

| 

| | | 

|<—Multiple DTE\DCE|<—Multiple single |<—Multilink | 
interface line interface interface 

| | | | 

gs = Single link interface 


Figure 2.3.5 Multilink Functional Organization 
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2.5.1 Field of Application 
The optional multilink procedure (MLP) described in “Multilink Frame Structure” 
through “List of Multilink System Parameters” on page 2-58 is used for data 
interchange over one or more single link procedures (SLPs), each conforming 
to the description in §§ 2.2, 2.3 and 2.4, in parallel between a DCE or DTE and a 
DTE or DCE/remote DTE respectively. The multilink procedure provides the fol- 
lowing general features: 


e achieve economy and reliability of service by providing multiple SLPs 
between a station and a remote station; 


e permit addition and deletion of SLPs without interrupting the service pro- 
vided by the multiple SLPs; 


e optimize bandwidth utilization of a group of SLPs through load sharing; 
e achieve graceful degradation of service when an SLP{s) fails; 


e provide each multiple SLP group with a single logical Data Link Layer 
appearance to the Packet Layer; and 


* provide resequencing of the received packets prior to delivering them to the 
Packet Layer. 


2.5.2 Multilink Frame Structure 


All information transfers over a SLP are in multilink frames conforming to one 
of the formats shown in Table 9. 


b+ 2 Octets —>| 


KEY: 
SLP = single line procedure 
MLP = multiple line procedure 
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2.5.2.1 Multilink Control Field 
The multilink control field (MLC) consists of two octets, and its contents are 
described in § 2.5.3. | 


2.5.2.2 Multilink Information Field 
The information field of a multilink frame is used primarily for the transfer of 
packets and, when present, follows the MLC. See §§ 2.5.3.2.3 and 2.5.3.2.4 for 
the various codings and groupings of bits, other than the packets, in the multi- 
link information field. 


2.5.3 Multilink Control Field Format and Parameters 


2.5.3.1 Multilink Control Field Format. 
The relationship shown in Table 10 exists between the order of bits delivered 
to/received from an SLP and the coding of the fields in the multilink control 
field. 


2-46 Architecture Reference 


TABLE 10 — Multilink Control Field Format 


[Multilink Control Field | 
[ Order of Bits Delivered to/Received from an SLP | 


Weight of bits in MN(S) 


— Internal View — 


| _——____________————— Multilink Control Field ————_________+ 
a Order of Bits Delivered to/Received from an SLP I 


‘ MNHs 


Weight of bits in MN(S) 


bits 9 —- 12 of 12-bit multilink send sequence number MNs 
bits 1 -— 8 of 12-bit multilink Send sequence number MNs 
Void Sequencing Bit 
Sequence Check Option Bit 

~ MLP Reset Request Bit 

| MLP Reset Confirmation Bit 


2.9.3.2 Multilink Control Field Parameters 
The various parameters associated with the multilink control field format are 
described below. See Table 10 and Figure 2-4 on page 2-51. | 


e Void Sequencing Bit - (V) 


The void sequencing bit (V) indicates if a received multilink frame 
shall be subjected to sequencing constraints. V = ‘1’ means 
sequencing is not required. 


Note: 


Y For purposes of this specification, ‘V=0’. 
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Sequence Check Option Bit - (S 


The sequence check option bit (S) is only significant when ‘V=1' 
(indicating that sequencing of received multilink frames is not 
required). ‘S=1' means no MN(S) number has been assigned. 
‘S=0’ means an MN(S) number has been assigned, so that 
although sequencing is not required, a duplicate multilink frame 
check may be made, as well as a missing multilink frame identi- 
fied. 


Note: 
For purposes of this specification, ‘S=0’. 


MLP Reset Request Bit - (R) 


The MLP reset request bit (R) is used to request a multilink reset 
{see § 2.5.4.2). ‘R = 0’ is used in normal communication, i.e., no 
request for a multilink reset. ‘R = 1’ ts used by the DCE MLP or 
DTE MLP to request the reset of the DTE MLP or DCE MLP state 
variables, respectively. In this ‘R = 1’ case, the multilink informa- 
tion field does not contain Packet Layer information, but may 
contain an optional 8-bit Cause Field that incorporates the reason 
for the reset. 


Note: 


The encoding of the Cause Field is a subject for further 
Study. 


MLP Reset Confirmation Bit - (C) 


The MLP reset confirmation bit {C) is used in reply to an ‘R = 1’ 
(see § 2.5.3.2.3) to confirm the resetting of the multilink state vari- 
ables (see § 2.5.4.2). ‘C = 0’ is used in normal communications, 
l.e., no multilink reset request has been activated. ‘C = 1’ is used 
by the local station MLP or remote station MLP in reply to a 
remote station MLP or local station MLP multilink frame, respec- 
tively, with ‘R = 1’, and indicates that the local station MLP or 
remote station MLP state variable reset process has been com- 
pleted by the local station or remote station, respectively. In this 
‘C = 1’ case, the multilink frame is used without an information 
field. 


Multilink Send State Variable - MVs 


The multilink send state variable MVs denotes the sequence 
number of the next in-sequence multilink frame to be assigned to 
an SLP. This variable can take on the value ‘0’ through °4095° 
(x‘000 - FFF’ (modulo 4096)). The value of MVs is incremented by 
‘1’ with each successive multilink frame assignment. 


Multilink Sequence Number - MNs 


Multilink frames contain the multilink sequence number MNs. 

Prior to the assignment of an in-sequence multilink frame to an 
available SLP, the value of MNs is set equal to the value of the 
multilink send state variable MVs. The multilink sequence number 
is used to resequence and to detect missing and duplicate multi- 
link frames at the receiver before the contents of a multilink frame 
information field is delivered to the Packet Layer. 


¢ Transmitted Multilink Frame Acknowledged State Variable - MVt 


MVt is the state variable at the transmitting DCE MLP or DTE MLP 
denoting the oldest multilink frame which is awaiting an indication 
that a DCE SLP or DTE SLP has received an acknowledgment from 
its remote DTE SLP or DCE SLP, respectively. This variable can 
take on the value ‘0’ through ‘4095’ (x‘000 - FFF’ (modulo 4096)). 
Some multilink frames with sequence numbers higher than MVt 
may already have been acknowledged. 


Multilink Receive State Variable - MVr 


The multilink receive state variable MVr denotes the sequence 
number at the receiving DCE MLP or DTE MLP of the next in- 
sequence multilink frame to be delivered to the Packet Layer upon 
receipt. This variable can take on the value ‘0’ through ‘4095’ 
(x‘Q00 - FFF’ (modulo 4096)). The value of MVr ts updated as 
described in § 2.5.4.3.2 below. Multilink frames with higher 
sequence numbers in the DCE MLP or DTE MLP receive window 
may already have been received. 


Multilink Window Size - MW 


MW is the maximum number of sequentially numbered multilink 
frames that the DCE MLP or DTE MLP may transfer to its SLPs 
beyond the lowest numbered multilink frame which has not yet 
been acknowledged. MW is a system parameter which can never 
exceed 4095 - MX. The value of MW shall be agreed to for a 
period of time with the Administration and shall have the same 
value for both the DCE MLP and the DTE MLLP for a given direction 
of information transfer. 


Note: 


Factors which will affect the value of parameter MW 
include, but are not limited to, single link trans- 
mission and propagation delays, the number of links, 
the range of multilink frame lengths, and SLP param- 
eters N2, T1 and k. 


The MLP transmit window contains the sequence 
numbers MVt to MVt+ MW-1, inclusive. 


The MLP receive window contains the sequence numbers MVr to 
MVr+MW-1, inclusive. Any multilink frame received within this 
window shall be delivered to the Packet Layer when its MNs 
becomes the same as MVr. 


Receive MLP Window Guard Region - MX 


MX is a system parameter which defines a guard region of multi- 
link sequence numbers of fixed size beginning at MVr+MW. The 
range of MX shall be large enough for the receiving MLP to recog- 
nize the highest MNs outside of its receive window that it may 
legitimately receive after a multilink frame loss has occurred. 


A multilink frame with sequence number MNs=Y received in this 
guard region indicates that those missing multilink frame(s) in the 
range MVr to Y-MW has(have) been lost. MvVr is then updated to 

Y-MW + 1. 
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Note: 


A number of methods may be selected in calculating a 
value for the guard region Mx: 


. Ina system where the transmitting MLP assigns hi in- 


sequence contiguous multilink frames at a time to the ith 
SLP, MX should be greater than or equal to the sum of the 
hi+1-hmin, where hmin equals the smallest hi encount- 
ered. Where there are L SLPs in the multilink group, MX 
should be greater than or equal to: 


L 
Sum hit+l-hming; or 
j=1 


. In a system where the transmitting MLP assigns on a rota- 


tion basis h in-sequence contiguous multilink frames at a 
time to each SLP, MX at the receiving MLP should be 
greater than or equal to h(L-1) +1, where L is the number 
of SLPs in the multilink group; or 


3. MX should be no larger than MW. 


Additional methods of selecting MX values are being studied 
by the CCITT. 


Increasing 
Numbers: 


MVt — Oldest multilink sequence number not yet acknowledged 


\ 
\ 


> MW —- Multilink window size 


MVs — Next multilink send sequence number to be used 


/ 
i 


Transmit Window 


Increasing 


Numbers: 
MVr — Oldest multilink sequence number not yet received 
> MW — Frames received in this range accepted 
/ 
< 

| \ 
\ > MX — Frames received in this range accepted but data 
| - loss in the receive window indicated 


Receive Window 


Figure 2-4. Parameter Descriptions 


2.5.4 Description of the Multilink Procedure (MLP) 
‘ The procedure below is presented from the perspective of the transmitter and 
gy receiver of multilink frames. 


The arithmetic is performed modulo 4096. 


2.5.4.1 Initialization 
The DCE or DTE will perform an MLP initialization by first resetting MVs, MVt 
and MVr to zero and then initializing each of its SLPs. Upon successful initial- 
ization of at least one of the SLPs, the DCE shall, and the DTE should, perform 
the multilink resetting procedure as described in § 2.5.4.2. An SLP initialization 
is performed according to § 2.4.4.1 of this specification. 


Note: 


An SLP that cannot be initialized should be declared out of service and 
appropriate recovery action should be taken. 
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+ 2.5.4.2 Multilink Resetting Procedures 


V 


The multilink resetting procedure provides the mechanism for synchronizing the 
sending and receiving MLPs in both the DCE and the DTE, when deemed neces- 
sary by either the DCE or the DTE. Exact cases where the MLP resetting proce- 
dures are invoked are for further study. Following a successful multilink 
resetting procedure, the multilink sequence numbering in each direction begins 
with the value ‘0’. 


Table Figure 2-3 on page 2-43 provides examples of the multilink resetting pro- 
cedures when initiated by either the DCE or the DTE, or by both the DCE and 
the DTE simultaneously. 


A multilink frame with ‘R = 1’ is used to request multilink reset, and (trans- 
mission and-reception of) a multilink frame with ‘C = 1° confirms that the multi- 
link reset process has been completed. An MLP resets (its) MVs and MVt to 
zero on transfer of (when it sends) a multilink frame with ‘R = 1’; and resets 
(its) MVr to zero on receipt of a multilink frame with ‘R = 1°. 


When the DCE MLP or DTE MLP initiates the resetting procedure, 


e it removes all of the unacknowledged multilink frames that are held in 
that MLP and its associated SLPs, and retains control of those frames. 


e Hereafter, the initiating MLP does not transfer a multilink frame with ‘R 
= C = 0’ until the reset process is completed. (One method to remove 
multilink frames in the SLP is to disconnect the data link of that SLP.) 


e The initiating MLP then resets its multilink send state variable MVs and 
e its transmitted multilink frame acknowledged variable MVt to zero. 


e The initiating MLP then transfers a multilink frame with ‘R = 1’ asa 
reset request on one of its SLPs and starts Timer MT3. The value of the 
MNs field in the ‘R = 1’ frame may be any value, since when ‘R = 1’ 
the MNs field is ignored by the receiving MLP. 


e The initiating MLP continues to receive and process multilink frames 
from the remote MLP, in accordance with the procedures as described 
in § 2.5.4.4 below 


e until it receives a multilink frame with ‘R = 1° from the remote MLP. 


An MLP which has received a multilink frame with ‘R = 1’ (reset request) in the 
normal communication status from an initiating MLP starts the (resetting) oper- 
ation as described (from (1) unless it has already initiated its own multilink 
resetting procedure) above; the MLP should receive no multilink frame with ‘R 
= C = 0’ from the other MLP until the reset process is completed. Any such 
multilink frame received is discarded. When an MLP has already initiated its 
own multilink resetting procedure and has transferred the multilink frame with 
‘R = 1’ to one of its SLPs for transmission, that MLP does not repeat the above 
operation upon receipt of a multilink frame with ‘R = 1° from the other MLP. 


IBM SNA X.25 DTEs that use the multilink procedure discard any multilink 
frames that are received following the receipt of a reset request (R = ‘1’) until 


the resetting procedure has been completed. 


Receipt of a frame with ‘R = 1° (reset request) causes the receiving MLP to 
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« deliver to the Packet Layer those packets already received and 
¢ to identify those multilink frames assigned to SLPs but unacknowledged. 


e The Packet Layer may be informed of the packet loss at the original 
value of MVr and 


e at any subsequent value(s) of MVr for which there has been no multilink 
frame received up to and including the highest numbered multilink 
frame received. The receiving MLP then 


¢ resets its multilink receive state variable MVr to zero. 


After an MLP assigns a multilink frame with ‘R = 1’ to one of its SLPs, it shall 
receive indication of successful or unsuccessful transmission from that SLP as 
one of the conditions before transferring a multilink frame with ‘C = 1°; when 
the initiating MLP then receives a multilink frame with ‘R = 1’, and has com- 
pleted the multilink state variable resetting operation described above, the initi- 
ating MLP transfers a multilink frame with ‘C = 1° (reset confirmation) to the 
other MLP. When an MLP has: 


e received a multilink frame with ‘R = 1’, 
e transferred a multilink frame with ‘R = 1’ on one of its SLPs, and 
¢ completed the multilink state variable resetting operation above, 


that MLP then transfers a multilink frame with ‘C = 1’ (reset confirmation) to 
the other MLP as soon as possible, given that indication of the successful or 


unsuccessful transmission of the ‘R = 1° Multiinik irame nas Deen receive 

from that MLP’s SLP. The ‘C = 1’ multilink frame Is a reply to the multilink 
frame with ‘R = 1°. The value of the MNs field in the above ‘C = 1’ frame may 
be any value, since when ‘C = 1’ the MNs field is ignored by the receiving 
MLP. The multilink sequence number MNs received in each direction following 


multilink reset will begin with the value zero. 


When an MLP uses only one SLP to transmit the multilink frame with ‘R = 1” 
and the multilink frame with ‘C = 1’, the MLP can transfer the multilink frame 
with ‘C = 1’ immediately after the multilink frame with ‘R = 1° without waiting 
for SLP indication of transmission completion. An MLP shail not retransmit a 
multilink frame with ‘R = 1’ or a multilink frame with ‘C = 1’ unless Timer MT3 
(see § 2.5.5.3 below) runs out. An MLP may use two different SLPs as long as 
one is used for transmitting the multilink frame with ‘R = 1° and the other is 
used for transmitting the multilink frame with ‘C = 1° following receipt of the 
SLP indication of successful or unsuccessful transmission of the ‘R = 1° multi- 
link frame. A multilink frame with ‘R = C = 1’ is never used. 


When an MLP receives the multilink frame with ‘C = 1’, the MLP stops its 
Timer MT3. The transmission of the multilink frame with ‘C = 1’ to a remote 
SLP and the reception of a multilink frame with ‘C = 1’ from the remote MLP 
completes the multilink resetting procedure for an MLP. The first multilink 
frame transferred with ‘R = C = 0’ shall have a multilink sequence number 
MNs value of zero. After an MLP transfers a multilink frame with ‘C = 1 to an 
OLP, the MLP may receive one or more multilink frames with ‘R = C = 0’. 
After an MLP receives a multilink frame with ‘C = 1’, the MLP may transfer one 
or more multilink frames R = € = ‘0’ to its SLP. 


When an MLP additionally receives one or more multilink frames with ‘R = 1’ 
between receiving a multilink frame with ‘R = 1’ and transferring a multilink 
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frame with ‘C = 1’, the MLP shall discard the extra multilink frames with ‘R = 
1’. When an MLP receives a multilink frame with ‘C = 1’, which is not a reply 
to a multilink frame with ‘R = 1’, the MLP discards the multilink frame with ‘C 
= 4". 


After an MLP transfers a multilink frame with ‘C = 1’ on one of its SLPs, the 
MLP may receive a multilink frame with ‘R = 1’ from the other MLP. The MLP | 
shall regard the multilink frame with ‘R = 1’ as a new reset request and shall 
start the multilink resetting procedure from the beginning. When an MLP which 
has not received a multilink frame with ‘R = 1’, transfers a multilink frame with 
‘R = 1’, and therefore receives a multilink frame with ‘C = 1’, the MLP shall 
restart the resetting procedure from the beginning. 


When Timer MT3 runs out, the MLP restarts the multilink resetting procedure 
from the beginning. The value of Timer MT3 shall be large enough to include 
the transmission, retransmission and propagation delays in the SLPs, and the 
operation time of the MLP that receives a multilink frame with ‘R = 1’ and 
responds with a multilink frame with ‘C = 1’. 


2.9.4.3 Transmitting Multilink Frames 


> 2.5.4.3.1.General 

= The transmitting DCE or DTE MLP shall be responsible for controlling the flow 
> of packets from the Packet Layer into multilink frames and then to the SLPs for 
a transmission to the receiving DTE or DCE MLP, respectively.: The functions of 
> the transmitting DCE or DTE MLP shall be to: 

> e accept packets from the Packet Layer: 

> e allocate multilink control fields, containing the appropriate sequence 

> number MNs, to the packets, 

oe e assure that MNs is not assigned outside the MLP transmit window (MW); 

> , = pass the resultant multilink frames to the SLPs for transmission: 

> e accept indications of successful transmission acknowledgements from the 
> SLPs; 

> « monitor and recover from transmission failures or difficulties that occur at 
= the SLP sublayer; and : 

> e accept flow control indications from the SLPs and take appropriate actions. 
> | 2.5.4.3.2 Transmission of Multilink Frames When the transmitting station MLP 

S accepts a packet from the Packet Layer, it shall place the packet in a multilink 


frame, set the MNs equal to MVs, assure that MNs is not assigned outside the 
transmit window (MW), set V, S, R and C to ‘0’, and then increment MVs by ‘1”:: 
In the following, incrementing send and receive state variables is in reference 
to a continuously repeated sequence series, i.e., 4095 is 1 higher than 4094, and 
0 is 1 higher than 4095 for modulo 4096 series. 


If the MNs is less than MVt + MW, and the remote station has not indicated a 
busy condition on all available station SLPs, the transmitting station MLP may 
then assign the new multilink frame to an available station SLP. The transmit- 
ting station MLP shall always assign the lowest MNs unassigned multilink frame 
first. Also, the transmitting station MLP may assign a multilink frame to more 
than one station SLP. 
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When the DCE or DTE SLP successfully completes the transmission of (a) multi- 
link frame(s) by receiving an acknowledgment from the remote station SLP, it 
shall indicate this to the transmitting station MLP. 


The transmitting station MLP may then discard the acknowledged multilink 
frame(s). As the transmitting station receives new indications of acknowledg- 
ments from the station SLPs, MVt shall be advanced to denote the lowest multi- 
link frame not yet acknowledged. 


Whenever a station SLP indicates that it has attempted to transmit a multilink 
frame N2 times, the station MLP will then assign the multilink frame to the 
Same or One or more other station SLPs unless the MNs has been acknowl- 
edged on some previous station SLP. The station MLP shall always assign the 
lowest MNs multilink frame first. 


Note: 


lf a station MLP implementation is such that a multilink frame is 
assigned to more than one station SLP (e.g., to increase the probability 
of successful delivery) there is a possibility that one of these multilink 
frames (i.e., a duplicate) may be delivered to the remote station MLP 
after an earlier one has been acknowledged (the earlier multilink frame 
would have resulted in the receiving station MLP having incremented its 
MVr and the transmitting station MLP having incremented its MVt). To 
ensure that an old duplicate multilink frame is not mistaken for a new 
frame by the receiving station MLP, it is required that the transmitting 
station MLP shall never assign a station SLP a new multilink frame with 
MNs equal to MNs’-MW-MX, where MNs’ is associated with a duplicate 
multilink frame that was earlier assigned to other station SLPs, until all 
station SLPs have either successfully transmitted the multilink frame 
MNs’ or have attempted the transmission the maximum number of 
times. 


Alternatively, the incrementing of MVt may be withheld until all station 
SLPs that were assigned the multilink frame MNs’ have either success- 
fully transferred the multilink frame MNs’ or have attempted the trans- 
mission the maximum number of times. These and other alternatives 
are for further study. 


Flow control is achieved by the window size parameter MW, and through busy 
conditions being indicated by the remote station SLPs. 


The station MLP will not assign a multilink frame with an MNs greater than 
MVt+MW-1. At the point where the next station multilink frame to be assigned 
has an MNs=MVt+ MW, the station MLP shall hold this and subsequent multi- 
link frames until an indication of an acknowledgement that advances MVt is _ 
received from the station SLPs. 


The remote station MLP may exercise flow control of the station MLP by indi- 
cating a busy condition over one or more remote station SLPs. The number of 
oLPs made busy will determine the degree of station MLP flow control realized. 
When the station MLP receives an indication of a remote station SLP busy con- 
dition from one or more of its station SLPs, the station MLP may reassign any 
unacknowledged multilink frames that were assigned to those station SLPs. 
The station MLP will assign the multilink frames containing the lowest MNs to 
an available station SLP as specified above. 
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In the event of a circuit failure, a station SLP reset, or a station SLP or remote 
station SLP disconnection, all station MLP multilink frames that were unac- 
Knowledged on the affected station SLPs shall be reassigned to an operational 
Station SLP(s) which is(are) not in the busy condition. 


2.5.4.4 Receiving Multilink Frames 
Any multilink frame less than two octets in length shall be discarded by the 
S receiving station MLP. 


Note: 


The procedures to be followed by the receiving station MLP when V 
and/or S is equal to ‘1’ are for further study. The procedures to be fol- 
lowed by the receiving station MLP when ‘R’ or ‘C’ is equal to ‘1’ are 
described in § 2.5.4.2 above. 


S When the station MLP receives multilink frames from one of the station SLPs, 

S the station MLP will compare the multilink sequence number MNs of the 
received multilink frame to its multilink receive state variable MVr, and act on 
the multilink frame as follows: 


° |f the received MNs is equal to the current value of MVr, t.e., is the next _ 
S expected in-sequence multilink frame, the station MLP delivers the packet 
to the Packet Layer. 


e |f the MNs is greater than the current value of MVr but less than 
S MVr+ MW + MX, the station MLP keeps the received multilink frame until 
S condition a) is met, or discards it if it is a duplicate. 


e if the MNs is other than a) and b) above, the multilink frame is discarded. 


> Note: 

> In case c) above, the recovery from desynchronization greater than MX 
= between the local and the remote MLP, i.e., the value of MNs assigned 

> to new multilink frames at the remote MLP is higher than MVr + MW + 
> MX at the local MLP, is for further study. 


1F 7) 


On receipt of each multilink frame, MVr is incremented by the station MLP in 


the following way: 
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i) If MNs is equal to the current value of MVr, the MVr is incremented 
by the number of consecutive in-sequence multilink frames that have 
been received. If additional multilink frames are awaiting delivery 
pending receipt of a multilink frame with MNs equal to the updated MVr, 
then Timer MT1 (see § 2.5.5.1 below) is restarted; otherwise, Timer MT1 
is stopped. 


li) If MNs is greater than the current value of MVr, but less than 
MVr+MW, MVr remains unchanged. Timer MI‘ is started, if not 
already running. 


iii) If MNs is > MVr + MW but < MVr + MW + MX, MVr is incre- | 
mented to MNs-MW-+1 and then the Packet Layer may be informed of 
the packet loss at the original value of MVr. As MVr is being incre- 
mented, if any multilink frame with MNs=MvVr has not yet been 
received, the Packet Layer may be informed of that packet loss also; if 
the multilink frame with MNs=MvVr has been received, it is delivered to 
the Packet Layer. After MVr reaches MNs-MW + 1, it will be incre- 


oe 
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mented further (as in i) above) until the first unacknowledged MNs is 
encountered. 


iv) If the MNs is other than that in 1), tt) and til) above, MVr remains 
unchanged. 


lf Timer MT1 runs out, MVr is incremented to the MNs of the next multilink 
frame awaiting delivery to the Packet Layer and then the Packet Layer may be 
informed of the packet loss at the original MVr. The procedure follows a) and 
i) above as long as there are consecutive in-sequence multilink frames which 
have been received. 


When flow control of the remote station MLP is desired, one or more station 
SLP(s) may be made to indicate a busy condition. The number of station SLPs 
made busy determines the degree of flow control realized. 


If the station MLP can exhaust its receive buffer capacity before resequencing 
can be completed, Timer MT2 (see § 2.5.5.2 below) may be implemented. 
Whenever a busy condition is indicated by the station MLP on all station SLPs, 
and multilink frames at the station MLP are awaiting resequencing, Timer MT2 
shall be started. When the busy condition is cleared on one or more station 
SLPs by the station MLP, Timer MT2 shall be stopped. 


If Timer MT2 runs out, the multilink frame with MNs=MvVr ts blocked and shall 
be considered lost. MVr shall be incremented to the next in-sequence number 
not yet received, and the packets contained in multilink frames with intervening 
multilink sequence numbers are delivered to the Packet Layer. Timer MT2 
shall be restarted if the busy condition remains in effect on all station SLPs and 
more multilink frames are awaiting resequencing. 


2.5.4.5 Taking an SLP Out of Service 


A station SLP may be taken out of service for maintenance, traffic, or perform- 
ance considerations. 


A station SLP is taken out of service by disconnecting at the Physical Layer or 
the Data Link Layer. Any outstanding station MLP multilink frames will be reas- 
signed to one or more other station SLPs, uniess the MNs has been previously 
acknowledged on some other station SLP. The usual procedure for taking a 
SLP out of service at the Data Link Layer would be to flow control the remote 
station SLP with an RNR frame, and then logically disconnect the station SLP 
(see § 2.4.4.3 above). 


If the station SLP Timer T1 has run out N2 times and the station SLP link reset- 


ting procedure is unsuccessful, then the station SLP will enter the disconnected 
phase, taking the station SLP out of service (see §§ 2.4.5.8 and 2.4.7.2 above). 
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Note: 


In case where all SLPs are out of service, the recovery mechanism is 
based on initiating the multilink resetting procedures. Other recovery 
procedures are for further study. 


2.5.5 List of Multilink System Parameters 


2.9.9.1 Lost-Frame Timer M11 (Multilink) 
Timer MT1 is used at a receiving station MLP to provide a means to identify 
during low traffic periods that the multilink frame with MNs equal to MVr is lost. 


2.5.5.2 Group Busy Timer MT2 (Multilink) 
Timer MT2 is provided at a receiving station MLP to identify a “blocked” multi- 
link frame condition (e.g., a buffer exhaust situation) that occurs before required 
resequencing can be accomplished. Timer MT2 is started when all station 
SLPs are busy and there are multilink frames awaiting resequencing. If Timer 
MT2 runs out before the “blocked” multilink frame MVr is received, the 
“blocked” multilink frame(s) is{are) declared lost. MVr is incremented to the 
value of the next in-sequence multilink frame to be received, and any packets in 
intervening multilink frames are delivered to the Packet Layer. 


Note: 
Timer MT2 may be set to infinity; e.g., when the receiving station always 
has sufficient storage capacity. 


2.5.5.3 MLP Reset Confirmation Timer MT3 (Multilink) 
Timer MT3 is used by the station MLP to provide a means of identifying that the 


remote station MLP multilink frame with the ‘C = 1’ that is expected following 
the transmission. of the station MLP multilink frame with ‘R = 1’, has not been 
received. 

2.6 LAP Elements of Procedure 


Applicable only to certain early IBM SNA X.25 DTE implementations and beyond 
the scope of this specification. j 


2.f 


Description. of the LAP Procedure 


Available only in certain early IBM SNA X.25 DTE implementations and beyond 
the scope of this specification. 
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Chapter 3. Description of Packet Layer DTE/DCE Interface 


This and subsequent sections relate to the transfer of packets at the DTE/DCE 
interface for both SNA-to-SNA connections and for SNA-to-non SNA con- 
nections. The procedures apply to packets that are successfully transferred 
across the DTE/DCE interface. It also covers the additional Packet Layer proce- 
dures necessary for two DTEs conforming to CCITT Recommendation X.25 to 
communicate directly (i.e., without an intervening packet-switched network) 
over a dedicated path or a circuit-switched connection. 


Each packet transferred across the DTE/DCE or DTE/DTE interface is contained 
within the data link layer information field which delimits its length, and only 
one packet Is contained within the information field. 


Note: 


Some networks require the data fields of packets to contain an 
integral number of octets. Transmission Ly the DTE of data fields 
not containing an integral number of octets to networks may cause 
a loss of data integrity. DTEs wishing universal operation on all 
networks should transmit all packets with data fields containing 
only an integral number of octets. Full data integrity can only be 
assured by exchange of octet-oriented data fields in both 
directions of transmission. 


IBM SNA X.25 DTEs transmit and receive packets with User Data fields that 
contain an integral number of octets only. 


This section covers a description of the packet layer interface for virtual call 
and permanent virtual circuit services. 


Note: 


Although the term ‘Switched Virtual Circuit’ (SVC) is not defined by 
CCITT Recommendation X.25 it is widely used as a synonym for 
virtual call (VC) service. 


For SNA-to-SNA connections, virtual circuits (virtual calls or permanent virtual 
circuits) are treated, by SNA, as real links that cai accommodate multiple SNA 
sessions. Permanent virtual circuits are managed like non-switched links while 
virtual calls are managed either like switched links or like non-switched links 
depending upon the implementation at the IBM SNA X.25 DTE. Except for the 
IBM 5973 Network Interface Adapter (NIA), IBM SNA X.25 DTEs must support 
‘Qualified’ data packets for Logical Link Control (QLLC) to perform adjacent 
SNA node physical services (see § 8.0). Adjacent SNA node physical services, 
segmentation and sequence numbering may be performed with an optional 
Physical Services Header (PSH) as described in Appendix J, “Physical Services 
Headers” only for compatibility with the IBM 5973 NIA. 


For SNA-to-non SNA connections, transformation between X.25 and SNA proto- 
cols may be performed at SNA boundary network nodes. In this environment 
several implementation approaches can be used as described in Appendix K, 
“SNA-to-non_SNA Architectural Considerations.” 
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SNA-to-SNA connections and SNA-to-non SNA connections differ only at the 
packet layer. Thus, the previous points (§§ 1.0 and 2.0) apply equally to both 
types of connection. In the following points (§§ 3.0, 4.0, 5.0, 6.0 and 7.0), func- 
tions, facilities, formats and procedures that apply only to SNA-to-non SNA con- 
nections are enclosed in brackets (e.q., [text]). 


Procedures for virtual circuit service (i.e., virtual call and permanent virtual 
circuit services) are specified in § 4.0. Packet formats are specified in § 5.0. 
Procedures and formats for optional user facilities are specified in §§ 6.0 and 
7.0. 


3.1 Logical Channels. 


To enable simultaneous virtual calls and/or permanent virtual circuits, logical 
channels are used. Each virtual call and permanent virtual circuit is assigned a 
logical channel group number (LCGN, less than or equal to 15) and a logical 
channel number (LCN, less than or equal to 255). For virtual calls, a logical 
channel group number and a logical channel numbe. are assigned during the 
call set-up phase. The range of logical channels used for virtual calls is agreed 
upon with the network Administration at the time of subscription to the service 
(see Appendix A, “Logical Channel Ranges”). For permanent virtual circuits, 
logical channel group numbers and logical channel numbers are assigned in 
agreement with the Administration at the time of subscription to the service 
(see Appendix A, “Logical Channel Ranges’). | 


The logical channel group number and the logical channel number may be 
managed as a Single twelve-bit entity (logical channel identifier - LCI). 


3.2 Structure of Packets 


Every packet transferred across the DTE/DCE interface consists of at least three. 
octets. These three octets contain a general format identifier (GFI), logical 
channel identifier (LCI) and a packet type identifier (PTI). Other fields are 
appended to packets as required (see § 5). 


Packet types and their use in association with various services are given in 
Table 14. 
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TABLE 14: Packet Types and Their Use in Various Services 
PACKET. TYPE SERVICE 
From DCE to DTE From DTE to DCE pve | PVC T/E 


CALL SET-UP AND CLEARING 


INCOMING CALL — (INC) at ae — (CRQ) 
CALL_CONNECTED — (CCN) CALL ACCEPTED — (CAC) 
CLEAR INDICATION — (CLI) CLEAR REQUEST - (CLR) 


DCE CLEAR CONFIRMATION — (NCC) DTE_CLEAR CONFIRMATION — (TCC) 


DATA [AND INTERRUPT] (2) 


DCE DATA — (NDT) DTE_DATA — (TDT) 
[DCE_INTERRUPT] — (NIN) [DTE_INTERRUPT] ~ (TIN) 
[DCE_INTERRUPT_ [DTE INTERRUPT 


CONFIRMATION] — (NIC) CONFIRMATION] — (TIC) 


FLOW CONTROL AND RESET (3,7) 


DCE_RR — (NRR) DTE_RR — (TRR) a a 
DCE_RNR — (NNR) DTE_RNR — (TNR) X X 
RESET INDICATION — (RSI) ro x 

RESET REQUEST — (RSR) x 
DCE RESET CONFIRMATION — + (NRC) DTE_RESET CONFIRMATION ~ (TRC) X 


RESTART T (4) 
RESTART INDICATION — (IRI) RESTART REQUEST — (IRR) 
DCE RESTART CONFIRMATION — (NSC) DTE_RESTART CONFIRMATION — (TRC) 


DIAGNOSTIC (5) 


DIAGNOSTIC — (DGN) a) 


REGISTRATION a) (6) 
REGISTRATION REGISTRATION 
CONFIRMATION — (RCN) REQUEST — (RRQ) 


Not necessarily available on all networks. 
Affects given Virtual Calls 
Affects given Permanent Virtual Circuits 
= Affects all VCs and PVCs at the DTE/DCE Interface 


See §§ 4.1 and 6.6 for procedures, § 5.2 for formats. 
— See § 4.3 for procedures and § 5.3 for formats. 
— See §§ 4.4 and 6.4 for procedures, §§ 5.4 and 5.7.1 for formats. 
— See § 3.3 for procedures, § 5.5 for formats. 
— See § 3.4 for procedures, § 5.6 for formats. 
— See § 6.1 for procedures, § 5.7/7.2 for formats. 
— DTE REJ Paekeee are not used. 
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3.3 Procedure for Restart 


The restart procedure is used to initialize or reinitialize the packet layer 
DTE/DCE interface {or DTE/DTE interface in the case of DTE/DTE operation). 
The restart procedure simultaneously clears all virtual calls and resets all per- 
manent virtual circuits at the interface (see § 4.5). 


Figure B-1 on page B-2 gives the state diagram which defines the logical 
relationships of events related to the restart procedure. 


Table C-2 “DCE State/Action Tables” on page C-2 specifies actions taken by 
the DCE upon receipt of packets from the DTE for the restart procedure. 


Appendix I, “Description of DTE Packet Layer Actions” specifies actions taken 
by the DTE on receipt of packets from the DCE for the restart procedure. 


3.3.1 Restart by the DTE 
The DTE may at any time, after link initialization is complete, request a restart 
by transferring across the interface a RESTART REQUEST packet and starting 
the Restart Request Response Timer (T20). The Diagnostic Code field in 
RESTART REQUEST packets is coded x‘00’ to indicate initial restart (see 
Appendix H, “DTE-Generated Diagnostic Codes” for SNA-to-SNA connections). 
The interface for each logical channel is then in the DTE_Restart_Request state 
(r2). In this state, the DTE will ignore all packets except 
RESTART CONFIRMATION, RESTART_INDICATION, REGISTRATION REQUEST 
(DTE/DTE environment only), REGISTRATION CONFIRMATION, and DIAG- 
NOSTIC packets. Therefore, higher layer entities must be able to cope with the 
various possible situations that may occur. 


The failure to receive a RESTART CONFIRMATION packet or a 

RESTART INDICATION packet before expiration of T20 after transmission of a 
RESTART REQUEST packet is considered an error. The restart procedure is 
retried up to a maximum number of times R20. After this the Packet Layer noti- 
fies the appropriate entity that it has not received a confirmation of the restart 
procedure. Each logical channel then remains in the DTE_Restart_Request 
state (R2). 


The DCE will confirm the restart by transferring a 

DCE RESTART CONFIRMATION packet placing the logical channels used for 
virtual calls in the Ready state (p1), and logical channels used for permanent 
virtual circuits in the Flow_Control_ Ready state (d1). 


Note: 
States p1 and d1 are specified in § 4. 


The DCE RESTART CONFIRMATION packet can only be interpreted universally 
as having local significance. The time spent in the DTE_Restart_Request state 
(r2) will not exceed time-limit T20 (see Appendix D, “DCE Time-outs and DTE 
Time-limits”). In this state, DTEs ignore all packets, except 

RESTART INDICATION and DCE RESTART CONFIRMATION. If the DCE does 
not confirm this restart within 200 seconds, the RESTART REQUEST packet can 
be retransmitted after the 200 second timer is reinitialized. If the total time. 
spent in state (r2) exceeds ‘n’ times 200 seconds, where ‘n > 1’, notification of 
failure of the DTE/DCE interface must be reported to a higher layer by IBM SNA 
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X.25 DTEs using the Diagnostic “Timer Expired - RESTART Packet” #52 (x‘34’). 
The DTE/DCE interface must be placed in an inoperative state. 


Note: 


[The Restarting Cause field in RESTART REQUEST packets on 
SNA-to-non_ SNA connections is set to x‘00’ and the Diagnostic Code 
field is coded according to Table E-1 (see Appendix E, “Network Gener- 
ated Diagnostic Codes”) ]. 


++++ 4 


3.3.2 Restart by the DCE 
The DCE will indicate a restart by transferring a RESTART_INDICATION packet 
S across the DTE/DCE interface. The interface for each logical channel (both DTE 
S and DCE) is then in the DCE Restart_Indication state (r3). In this state of the 
DTE/DCE interface, the DCE will ignore all packets except for 
S RESTART REQUEST and DTE RESTART CONFIRMATION. In this state, the DTE 
S considers subsequent receipt of any packet, other than another 
S RESTART INDICATION, REGISTRATION REQUEST (DTE/DTE environment only), 
S REGISTRATION CONFIRMATION, and DIAGNOSTIC packets as an error. It dis- 
S cards any such packet and transmits a RESTART REQUEST packet with a cause 
S indicating “DTE-Originated” and the diagnostic “Packet Type Invalid For State 
. 


io. 
S Note: 
S In a DTE/DTE environment, the RESTART INDICATION packet received 
S by one DTE is the same as the RESTART REQUEST packet transmitted 
S by the other DTE. 


IBM SNA X.25 DTEs report restarting cause and diagnostic codes contained in 
RESTART INDICATION packets to a higher layer. 


The DTE will confirm the restart by transmitting a 

DTE RESTART CONFIRMATION packet across the DTE/DCE interface, before 
timer T10 elapses, and placing all logical channels used for virtual calls in the 
READY state (p1) and all logical channels used for permanent virtual circuits in 
the Flow_Control_Ready siate (d‘). 


The action taken by the DCE when the DTE does not confirm the restart within 
time-out T10 are given in Appendix D, “DCE Time-outs and DTE Time-limits” 


3.3.3 Restart Collision 
Restart collision occurs when a DTE and a DCE simultaneously transfer a 
RESTART REQUEST and a RESTART INDICATION packet. When this occurs, 
S the DCE and the DTE will consider the restart to be complete. The DCE will not 
expect a DIE RESTART CONFIRMATION packet and will not transfer a 
DCE RESTART CONFIRMATION packet. The DTE will not transmit nor expect to 
receive a RESTART CONFIRMATION packet. However, if the procedures in § 
3.3.5 are used, then the DTE must determine whether the Restarting Cause 
Field in the RESTART INDICATION packet indicates “DTE originated.” If so, then 
the DTE must take no other action except to transmit another 
RESTART REQUEST packet after some randomly-chosen time delay. 
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IBM SNA X.25 DTEs do not expect a DCE_ RESTART CONFIRMATION packet and 
do not transfer a DTE_RESTART_CONFIRMATION packet when a restart colli- 
sion occurs. This places all logical channels used for virtual calls in the Ready 
state (p1), and all logical channels used for permanent virtual circuits in the 
Flow_Control. Ready state (d1). 


s 3.3.4 Restart Confirmation 


S 
NS) 
S 


Rana A HM 


AMA A M|M io) 


Ann rniyn 


mM HNnA HAA RAN ARN 


Tf | 


When a DTE is prepared to acknowledge a restart, it transmits across the inter- 
face a RESTART CONFIRMATION packet. At this time, the restarting procedure 
is considered completed. 


Having initiated a restarting procedure, the DTE considers the restarting proce- 
dure completed when it receives a RESTART CONFIRMATION packet. 


When the restarting procedure is completed, each Virtual Call logical channel is 
in the Ready state (p1) whereas each Permanent Virtual Circuit logical channel 
is in the Flow.Control_ Ready state (d1). 


In a network environment, the RESTART CONFIRMATION packet received from 
a DCE can only be interpreted universally as having local significance. 


3.3.5 Determining “DTE” or “DCE” Characteristics 


This section describes how the restart procedure can be used to determine 
whether the DTE acts as a DCE or maintains its role as a DTE with respect to 
logical channel selection during Virtual Call establishment and resolution of 
Virtual Call collision. 


When prepared to initialize the Packet Layer, the DTE must initiate the restart 
procedure (i.e., transmit the RESTART REQUEST packet). The determination is 
based on the response received from the DCE/remote DTE, as outlined below. 


a) When the DTE receives a RESTART_INDICATION packet with a 
restarting cause code that is not “DTE-Originated” ({i.e., it came 
from a DCE), then the DTE must follow the procedures in §§ 4.2, 
4.3, and 4.4 as appropriate and maintain its role as a DTE. 


b) If the DTE receives a RESTART INDICATION packet with a 
restarting cause code of “DTE-Originated” (i.e., it came from 
another DTE) and it does not have a. unconfirmed 
RESTART REQUEST packet outstanding (i.e., no restart colli- 
sion), then the DTE must confirm the restart (as in § 4.4) and act 
as a DCE. 


c) If the DTE receives a RESTART_INDICATION packet with a 
restarting cause code of “DTE-Originated” (i.e., it came from 
another DTE) and it does have an unconfirmed 
RESTART REQUEST packet outstanding (i.e., a restart collision), 
the DTE must consider this restart procedure completed (as in § 
4.3) but must take no other action except to transmit another 
RESTART REQUEST packet after some randomly-chosen time 
delay. 


d) If the DTE issues a RESTART REQUEST packet that is subse- 
quently confirmed with a RESTART CONFIRMATION packet (as 
in § 4.4), then the DTE must maintain its role as a DTE. 
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Note: 


lf a DTE operates only in a DTE/DCE environment or a DTE/DTE environ- 
ment where, by administration, the roles can be predetermined and 
fixed, then the procedures discussed above are not needed. in these 
cases, the DTE may be initialized to act in the appropriate manner. 


3.4 Error Handling 


Table C-1 specifies the reaction of the DCE when special error conditions are 
encountered. Other error conditions are discussed tn § 4.0. Table I-1 in 
Appendix |, “Description of DTE Packet Layer Actions” specifies the reaction of 
IBM SNA X.25 DTE when special error situations are encountered. 


3.4.1 Diagnostic Packet 


The DIAGNOSTIC packet is applicable to both DTE/DCE and DTE/DTE environ- 
ments. However, in the former. only a DCE may transmit a DIAGNOSTIC 
packet. In a DTE/DTE environment, a DTE may tr. nsmit a DIAGNOSTIC packet 
only if it’s generation can be suppressed when connected to a network. 


The DIAGNOSTIC packet is used by some networks to indicate error conditions 
under circumstances where the usual methods of indication (i.e., reset, clear 
and restart with cause and diagnostic) are not appropriate (see Tables C-1 and 
D-1). The DIAGNOSTIC packet from the DCE supplies information on error situ- 
ations that are considered to be unrecoverable at the packet layer of CCITT 
Recommendation X.25; the information provided in the Diagnostic Code and 
Diagnostic Explanation fields of DIAGNOSTIC packets permit an analysis of the 
error and recovery by higher layers at the DTE if desired or possible. The con- 
tents of Diagnostic Code and Diagnostic Explanation fields of DIAGNOSTIC 
packets must be reported to a higher layer in the DTE. No state transition takes 
place on the logical channel to which the DIAGNOSTIC packet is related. 


A DIAGNOSTIC packet is issued only once per particular instance of an error 
condition. No confirmation is required to be issued by the DTE on receipt of a 
DIAGNOSTIC packet. After issuing a DIAGNOSTIC packet, the DCE maintains 
the logical channel to which the DIAGNOSTIC packet is related in the same 
state as that when the DIAGNOSTIC packet was generated. 


3.4.2 Nonreceipt of window-rotation information 


The procedures described in this section may optionally be implemented by a 
DTE to recover from nonreceipt of window-rotation information (i. e., nonreceipt 
of a Pr to rotate the window after transmission of DATA packets). It is strongly 
recommended that a higher layer protocol be used to effect such recovery 
rather than these procedures. 


Nonreceipt of window-rotation information from the viewpoint of the DTE trans- 
mitting the DATA packets can occur because of situations such as: 


a) loss of transmitted DATA packets, up to an entire window’s 
worth of DATA packets (in the event that such a loss occurs, the 
transmitting DTE will not receive packets that rotate the 
window); 
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b) loss of a packet containing a Pr that rotates the window 
(packets used for conveying a Pr are RR, RNR, DATA, and 
REJECT (if subscribed to) packets): 


less than a full window’s worth of DATA packets with the D-bit 
set to 0 was transmitted (the DCE (or DTE if DTE/DTE), under 
normal circumstances, is only required to effect window rotation 
to meet the throughput class and to acknowledge DATA packets 
with the D-bit set to 1); and 


d) the DCE (or DTE if DTE/DTE) is effecting flow control by allowing 
the window to close (i. e., without sending an RNR packet) when 
receiving DATA packets with the D-bit set to 0 because of a tem- 
porary lack of resources or other reasons. 


> 


Failure to receive window-rotation information, depending on the reason, can 
lead to a condition in which the transmitting DTE is “flow-control inhibited” at 
the packet layer. If the window has closed, then the transmitting DTE may not 
transmit any more DATA packets because of the flow-control mechanisms 
defined in “Flow Control” on page 4-14. The DTE retnains flow-control inhibited 
until its transmission window is rotated and it is not explicitly flow controlled by 
an RNR packet. Of particular concern are items (a) and {b) above, since the 
DTE can remain flow-control inhibited indefinitely. This condition is referred to 
as “flow-control lockout.” 


s 3.4.2.1 Optional procedures at the transmitting DTE 
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To recover from non receipt of window-rotation information, a DTE may start a 
Window Rotation Timer (T25) when a DATA packet is transmitted across the 
interface. When a Pr is received that rotates the window, the timer is restarted 
if there are any previously-transmitted DATA packets still in the window or if 
additional DATA packets are then transmitted; otherwise, the timer is cancelled. 
lf a Pr that rotates the window is not received before expiration of T25, then the 
transmitting DTE should reset the logical channel. When resetting the logical 
channel, the DTE indicates the cause as “DTE Originated” with the diagnostic 
“Timer Expired Or Retransmission Count Surpassed For DATA Packet 
Transmission”. 


Note: 


A DCE or DTE receiving DATA packets is not obligated to rotate the 
window in such a timely fashion so as to prevent the transmitting DTE’s 
T25 timer from expiring (for example, see items (c) and (d) of section 
3.4.2). Therefore, the procedure outlined above should be used with 
caution. 


3.4.2.2 Optional procedures at the receiving DTE 


To decrease the probability of a lost window-rotation indication packet, the DTE 
may send a RR. RNR, DATA, or REJECT (if subscribed to) packet every T24 time 
units (i. e., at the expiration of the Window Status Transmission Timer) while the 
logical channel is in the FLOW CONTROL READY state (d1). If T24 units have 
elapsed since the last transmission of a window-rotation indication packet, then 
either an RR or an RNR is sent. The packet that is sent should reflect the 
current condition of the DTE that transmits it. Thus, if the DTE is unable to 
accept more DATA packets, then an RNR packet is transmitted; otherwise, an 
RR packet is transmitted. These packets contain a Pr corresponding to the 
most recently-received correct DATA packet. This Pr then becomes the lower 
window edge at the transmitting DTE. 
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The above procedure does not preclude the use of additional algorithms for 
rotation of the window. This procedure merely attempts to ensure that once a 
decision is made to rotate the window, the transmission of that decision will be 
effected even if the original packet is lost. 


Note: 


In a DTE/DCE environment, use of the above procedure at one DTE/DCE 
interface may not have any effect on the other DTE/DCE interface. 


3.4.3. Receipt of erroneous DATA packets 


The normal operation of data transfer requires that DATA packets be received 
in sequence, be no larger than the maximum-allowed packet size for the 
current data transfer operation, and contain an integral number of octets in the 
User Data Field. Receipt of a DATA packet with a nonconsecutive Ps value (i. 
e., Ps not equal to Ps +1, modulo 8, or modulo 128 when extended), with a User 
Data Field length greater than the allowed maximum, or with a User Data Field 
not octet aligned is considered an error. | 


Two alternatives are available to a DTE for recovering from the errors 
described above. They are: 


a) ignore the erroneous DATA packet and reset the logical channel 
with a cause indicating “DTE Originated” and one of the fol- 
lowing diagnostics as appropriate: 


e Invalid Ps, 
e Packet Too Long, or 
« Nonoctet Aligned Data Field; 


b) ignore the erroneous DATA packet and transmit a REJECT 
packet with a Pr equal to the Ps expected in the next in- 
sequence DATA packet. 


This alternative may be used only if agreement has been 
reached on the use of the Packet Retransmission Facility with 
the interfacing DCE (DTE if DTE/DTE). Furthermore, in a 
DTE/DCE environment, packet retransmission by a DCE as a 
result of receiving a REJECT packet only carries local signif- 
icance. That is, a DCE will respord to the REJECT packet by 
retransmitting the requested DATA packet across the local inter- 
face {a DCE does not transmit a REJECT packet to the remote 
DTE). 


The standard mode of recovery requires that the logical channel be reset. 
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For the most part, much of the Packet Layer protocol described herein is inde- 
pendent of whether the DTE is connected to a DCE ({i.e., X.25 network environ- 
ment) or directly to another DTE. However, there are certain procedures within 
X.25 that are not mandatory of a DTE but are required in a DTE/DTE environ- 
ment. To minimize the number of differences that arise when considering 
whether connection is to a DCE or to another DTE, the following procedures are 
always required of a DTE: 


e the Address Length Fields and the Facility Length Field are required in 
CALL ACCEPTED packets even if they indicate that no address and facility 
information, respectively, are present: 


e the Diagnostic Code Field in RESTART REQUEST, CLEAR REQUEST, and 
RESET REQUEST packets must be supplied even if it indicates “No Addi- 
tional Information” (that is, although specific diaynostics are defined for par- 
ticular error situations, a DIE may use more general codes as discussed in 
Note 1 of Table E_ 1); | 


e a DATA packet whose User Data Field is less than the maximum allowed 
and which has D=0 and M=1 should not be transmitted; and 


e upon notification that the Data Link Layer has completed its initialization 
procedures or that it has recovered from a failure in which the Data Link 
Layer was in the disconnected phase, the DTE must transmit a 
RESTART REQUEST packet across the interface. 


still, for a few of the procedures described in the following sections, consider- 
ation must be given to whether the DTE is connected to a DCE or another DTE. 
For a DTE/DTE environment, these considerations are listed below. 


e One of the DTEs must act as a DCE for 
— logical channel selection during Virtual Call setup (see Table A-1), 
— resolution of Virtual Call collision (see § 4.1.6). 


(This choice is made independently for each of the DTE’s Packet Layer enti- 
ties.) 


e A DTE must be able to accept a RESTART INDICATION packet with a 
Restarting Cause of “DTE-Originated”, an event which does not occur in a 
DTE/DCE environment. 


e A DTE should not receive a RESTART_, CLEAR_, or RESET_INDICATION 
packet with a Cause other than “DTE-Originated” (although this may occur 
in a DTE/DCE environment). Therefore, the DTE may either handle such a 
packet as it does in a DTE/DCE environment (i.e., process the packet 
normally) or treat it as an error (DTE/DTE environment only). 


e A DTE may transmit a DIAGNOSTIC packet in the appropriate circum- 
stances (see § 3.4.1) only if its generation can be suppressed when con- 
nected to a network. 


e A DTE may either ignore or treat as an error the receipt of facility codes 
that do not apply to a DTE/DTE environment. 
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Use of the optional On-line Facility Registration Facility (see § 6.1) requires 
agreement for each direction of registration procedure initiation. That is, 
for a given direction of registration procedure initiation, agreement to use 
this facility permits the initiating DTE to transmit REGISTRATION REQUEST 
packets and requires the responding DTE to process received 
REGISTRATION REQUEST packets. (In a DTE/DCE environment, a DTE will 
not receive a REGISTRATION REQUEST packet. 


Use of the optional Packet Retransmission Facility (see § 6.4) requires 
agreement for each direction of DATA packets. That is, for a given direction 
of transmission of DATA packets, agreement to use this facility permits the 
destination DTE to transmit REJECT packets and requires the source DTE to 
process received REJECT packets. (In a DTE/DCE environment, a DTE will 
not receive a REJECT packet.) 


Use of the optional Fast Select Facility (see § 6.16) must be agreed to by 
both DTEs prior to transmission of any call setup packets which utilize this 
facility. (In a DTE/DCE environment, such prior agreement is not required - 
a DTE may always use this facility at call setup.) 


A called DTE which subscribes to the 
Flow_Control_ Parameter Negotiation Facility (see § 6.12) and/or the 
Throughput_Class Negotiation Facility (see § 6.13) will not receive, in an 
INCOMING CALL packet, a facility indication from which to negotiate if the 
calling DTE is satisfied with the default values and, thus has not included 
the facility request in its CALL REQUEST packet. In a similar manner, a 
calling DTE which subscribes to these facilities will not receive, in a 

CALL CONNECTED packet, a facility indication if ine caiied DTE ts satisfied 
with the values in the INCOMING CALL packet and thus has not included a 
facility request in its CALL ACCEPTED packet. (In a DTE/DCE environment, 
these facility indications are always present if the DTE has subscribed to 
these facilities.) 


3.5.2 Operation Over Circuit-Switched Connections 
Most communications over a circuit-switched connection are between DTEs that 
have been arranged, by some prior administrative procedure, to be compatible. 
Agreement must be reached, for example, as to what logical channels will be 
used, the window sizes to be used, and a number of other items pertaining to 
Packet Layer operation. In some cases, however, it may be desirable to allow 
for random communications, where one DTE accesses another DTE via a 
circuit-switched connection without prior agreement (for example, an electronic 
mail-order service). To allow for this, the following subset of the Packet Layer 
procedures will be used: 


the interface shall consist of a single two-way Virtual Call logical channel 
using Identifier 1; 


the procedures described in § 3.3.4 are required; 


the default values for all applicable parameters listed in Table D-1 apply; 
parameters 124, T25, T27, T28, R25, R27, and R28 and the procedures in §§ 
6.1 and 6.4 do not apply; 


the reset procedures shall apply if erroneous DATA packets are received; 
and 


no optional user facilities shall be allowed. 
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Extensions beyond this basic set of procedures and capabilities (e.g., through 
the use of the On-line Facility Registration Facility - see § 6.1) are being 
pursued in conjunction with CCITT work on Recommendation X.32 
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Procedures for two types of virtual circuit services are included in CCITT 
Recommendation X.25 as follows: 


1. Virtual Call (Switched Virtual Circuit) services, and 


2. Permanent Virtual Circuit services. 


4.1 Procedure for Virtual Call Service 


Figure B-1 on page B-2, Figure B-2 on page B-3 and Figure B-3 on page B-4 
show the state diagrams which define the events at the Packet Layer DTE/DCE 
interface for each logical channel used for virtual calls. 


Appendix C, “Packet Layer DCE Actions” gives details of the action taken by 
the DCE on receipt of packets in each state shown in Appendix B, “Packet 
Layer DTE/DCE Interface State Diagrams.” 


Appendix I, “Description of DTE Packet Layer Actions” gives details of the 
actions taken by DTEs on receipt of packets in each state shown in Appendix B, 
“Packet Layer DTE/DCE Interface State Diagrams.” 


The call set-up and clearing procedures described in the following points apply 
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independently to each iogical Channel assigned for ine Virtual Cali service at 


the DTE/DCE or DTE/DTE interface. 


4.1.1 Ready State 


If there is no call in existence, a logical channel used for Virtual Calls is in the 
Ready state (p1). 


4.1.2 Call Request Packet 


The calling DTE indicates a call request by transferring a CALL REQUEST 
packet across the DTE/DCE or DTE/DTE interface and by starting the Call 
Request Response Timer (T21). The logical channel, selected for the call by the 
DTE, is then in the DTE Waiting state (p2). The CALL. REQUEST packet 
includes the called DTE address. 


Notes: 


1. A DTE address may be a network address or any other DTE identifica- 
tion agreed upon for a period of time between the DTE and the DCE or 
remote DTE (DTE/DTE). 


2. If the DTE maintains its role as a DTE, then the CALL REQUEST packet 
should use the logical channel in the Ready state (r1) with the highest 
number in the range that has been agreed upon with the network 
Administration or remote DTE (DTE/DTE) (see Appendix A, “Logical 
Channel Ranges”). In a DTE/DTE environment, however, if the DTE acts 
as a DCE for these procedures, then it chooses a logical channel in the 
READY state (p1) starting at the low end of the range of logical chan- 
nels. Thus, the risk of call collision is minimized. 
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The failure to receive a CALL_ CONNECTED packet or a CLEAR_INDICATION 
packet before expiration of timer T21 after transmission of a CALL REQUEST 
packet is considered an error. The Packet Layer clears the call with a cause 
indicating “DTE Originated” and the diagnostic “Timer Expired For Call 
Request.” 
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4.1.3 Incoming Call Packet 
The DCE will indicate that there is an incoming call by transferring an 
INCOMING CALL packet across the DTE/DCE interface. This places the logical 
channel, selected for the call by the DCE, in the DCE Waiting state (p3). 


The incoming call packet will use the logical channel in the Ready state with 

the lowest number (see Appendix A, “Logical Channel Ranges”). The 

INCOMING CALL packet includes the calling DTE address. The contents of the 
+ called DTE address field are ignored by the packet layer of IBM SNA X.25 DTEs. 
However, the address information and any data received as part of this packet 
must be forwarded to a higher layer entity. In addition, optional user facility 
information may also be passed to a higher layer entity. 
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Notes: 


1. ADTE address may be a DTE network address or any other DTE identifi- 
cation agreed upon for a period of time between the DTE and the DCE. 


S 2. In a DTE/DTE environment, the INCOMING CALL packet received by 
S one DTE is the same as the CALL_REQUEST packet transmitted by the 
S other DTE. 


4.1.4 Call Accepted Packet 
The called DTE shall indicate its acceptance of the call by transferring a 
CALL ACCEPTED packet specifying the same logical channel as that of the 
INCOMING CALL packet, before timer 111 elapses. This places the specified 
S logical channe! in the Flow_Control Ready substate of Data Transfer state (p4). 


S The decision of whether to accept a call is made by a higher layer entity before 
S a CALL ACCEPTED packet may be returned by the Packet Layer. Furthermore, 
S it may provide data to be returned to the calling DTE as part of the 

S CALL ACCEPTED packet. However, a call may be rejected without informing a 
S higher layer entity of its receipt, for reasons local to the Packet Layer (for 

S example, a format error in the INCOMING CALL packet). 


S Note: 

S A CALL ACCEPTED packet is not returned if the INCOMING CALL 
S packet indicates the Fast Select Facility with a restriction on the 
S response. 


If the called DTE does not accept a call by a CALL_ACCEPTED packet, or does 
not reject it by a CLEAR REQUEST packet as described in § 4.1.7, within 
time-out T11 (see Appendix D, “DCE Time-outs and DTE Time-limits”), the DCE 
will consider it is a procedure error on the part of the called DTE and clear the 
virtual call according to the procedure described in § 4.1.8. 
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4.1.5 Call Connected Packet 


The receipt of a CALL_ CONNECTED packet by the calling DTE specifying the 
same logical channel as that specified in the CALL REQUEST packet indicates 
that the call has been accepted by the called DTE by means of a 

CALL ACCEPTED packet. This places the specified logical channel in the 
Flow_Control_ Ready substate (D1) of Data Transfer state (p4). 


Any address information and any data received as part of the 

CALL CONNECTED packet must be forwarded to a higher layer entity. In addi- 
tion, optional user facility information may also be passed to a higher layer 
entity. 


Note: 


A In a DTE/DTE environment, the CALL_ CONNECTED packet received by 
on DTE is the same as the CALL ACCEPTED packet transmitted by the 
other DTE. 


The time spent in the DTE Waiting state (p2) will not exceed time-limit T21 (see 
Appendix D, “DCE Time-outs and DTE Time-limits”}. 


4.1.6 Call Collision 


Call collision occurs when a DTE transmits a CALL REQUEST packet and then 
receives an INCOMING CALL packet specifying the same logical channel. 


When this occurs, the DCE will proceed with the CALL REQUEST and cancel the 
INCOMING CALL. 


Further action by the DTE is dependent on whether the DTE maintains its role 
as a DTE or acts as a DCE for resolving call collision. 


e If the DTE maintains its role as a DTE, then it should ignore the 
INCOMING CALL packet and wait for the response from the DCE/remote 
DTE. The DTE should receive either a CALL CONNECTED packet (if the call 
is accepted by the remote DTE) or a CLEAR_INDICATION packet for the 
same channel as that in the CALL REQUEST packet. 


¢ In a DTE/DTE environment, if the DTE acts as a DCE, then it must cancel its 
call request and decide whether to transmit a CALL ACCEPTED packet or a 
CLEAR REQUEST packet. 


IBM SNA X.25 DTEs in a DTE/DCE environment discard the INCOMING CALL 
packet in the event of call collision. 


4.1.7 Clearing by the DTE 


The DTE may indicate call clearing, at any time, by transferring a 

CLEAR REQUEST packet across the interface (see § 4.5) and starting the Clear 
Request Response Timer (123). The logical channel is then in the 

DTE Clear Request state (p6). In this state, the DTE accepts only 

CLEAR CONFIRMATION and CLEAR_INDICATION packets. Other types of 
packets are ignored by the DTE. Therefore, higher layer entities must be able 
to cope with the various possible situations that may occur. When the DCE is 
prepared to free the logical channel, the DCE will transfer a 

DCE CLEAR CONFIRMATION packet specifying the same logical channel 
across the interface. The logical channel is then in the Ready state (p1). 
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The DCE CLEAR CONFIRMATION packet can only be interpreted universally as 
having local significance; however, within some Administrations’ networks, 
CLEAR_CONFIRMATION may have end-to-end significance. In all cases, the 
time spent in the DTE_ Clear Request state (p6) will not exceed time-limit T23 
(see Appendix D, “DCE Time-outs and DTE Time-limits”). Ifa 

DCE CLEAR CONFIRMATION packet is not received before timer T23 expires, 
the CLEAR REQUEST packet will be retransmitted after timer T23 is reinitial- 
ized. If the total time spent in state (p6) exceeds ‘R23’ times T23, where ‘R23 > 
1’, notification of the clear failure must be given to a higher layer by the DTE 
using appropriate DTE-Generated Cause and Diagnostic codes (see 

Appendix H, “DTE-Generated Diagnostic Codes”); the logical channel remains 
in the DTE_CLEAR_ REQUEST state (p6). 


The CLEAR_REQUEST packet may contain data provided by a higher layer 
entity to be sent to the remote DTE. This may be done only if the 
CALL_REQUEST and INCOMING CALL packets had indicated the 


Fast_Select_Facility. 


It is possible that subsequent to transferring a CLEAR REQUEST packet the DTE 
will receive other types of packets, depending upon the state of the logical 
channel, before receiving a DCE CLEAR CONFIRMATION packet. Any such 
packets are discarded by IBM SNA X.25 DTEs. 


Note: 


The calling DTE may abort a call by clearing it before it has received a 
CALL CONNECTED or CLEAR_INDICATION packet. In this case, the 
DTE may not transmit data in the CLEAR REQUEST packet. 


The called DTE may refuse an incoming call by clearing it as described in this 
point rather than.transmitting a CALL_ACCEPTED packet as described in § 
4.1.4. The called DTE must provide the reason for refusing an incoming call by 
placing an appropriate diagnostic code {see Appendix H, “DTE-Generated Diag- 
nostic Codes” on page H-1) in the Diagnostic Code field of the . 
CLEAR_REQUEST packet. 


4.1.8 Clearing by the DCE 


The DCE will indicate call clearing by transferring a CLEAR_INDICATION packet 
across the DTE/DCE interface (see § 4.5). The logical channel is then in the 
DCE_ Clear Indication state (p7). In this state, ifthe DTE receives any packet 
other than another CLEAR_INDICATION packet, it discards the packet and trans- 
mits a CLEAR_REQUEST packet with a cause indicating “DTE Originated” and a 
diagnostic “Packet Type Invalid For State p/7.” The DTE shall respond to the 
CLEAR_INDICATION packet by transferring a DTE_ CLEAR CONFIRMATION 
packet, before time-out T13 elapses. The logical channel is then in the Ready 
State (p1). The clearing cause code, as well as the diagnostic code and an indi- 
cation that a clearing procedure has taken place is passed to a higher layer 
entity. Any data and optional user facility information received in the 
CLEAR_INDICATION packet must also be forwarded to a higher layer entity. 


The actions taken by the DCE when a DTE does not confirm a call clearing 
within time-out T13 are given in Appendix D, “DCE Time-outs and DTE Time- 
limits.” 
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4.1.9 Clear Collision 
| A clear collision occurs when a DTE and a DCE simultaneously transfer a 
CLEAR REQUEST packet and a CLEAR_INDICATION packet specifying the same 


S logical channel. In this event, the DCE and the DTE will consider that the call 
S clearing is completed. Neither the DTE nor the DCE will expect a 
S CLEAR CONFIRMATION packet and neither will transfer a 
CLEAR CONFIRMATION packet. This places the logical channel in the Ready 
state (p1). 


4.1.10 Unsuccessful Cail 
lf a call cannot be established, the DCE transfers A CLEAR_INDICATION packet 
Specifying the logical channel indicated in the CALL REQUEST packet. IBM 
SNA X.25 DTEsS must report the contents of network generated call clearing 
cause and diagnostic code fields to a higher layer. 


4.1.11 Call Progress Signals 
The DCE will be capable of transferring to the DTE Clearing Call Progress 
Signals as specified in CCITT Recommendation X.Y6. 


Clearing Call Progress signals will be carried in CLEAR_INDICATION packets 
which will terminate the call to which the packet refers. The method of coding 
CLEAR_INDICATION packets containing Call Progress Signals is detailed in § 
5.2.3. IBM SNA X.25 DTEs must report all clearing Call Progress Signals to a 
higher layer. 


4.1.12 Data Transfer State | 
The procedures for the control of packets transferred between a DTE and a DCE 
in the Data_Transfer state {p4) are described in “Procedures for Data [and 
Interrupt] Transfer” on page 4-6. ~ 


4.2 Procedures for Permanent Virtual Circuit Service 


Figure B-1 on page B-2 and Figure B-4 on page B-5 show the state diagrams 
which give a definition of events at the packet layer DTE/DCE interface for 
logical channels assigned for permanent virtual circuits. 


Appendix C, “Packet Layer DCE Actions” gives details of the action taken by 
DCEs on receipt of packets in each state shown in Appendix B, “Packet Layer 
DTE/DCE Interface State Diagrams.” 


Appendix I, “Description of DTE Packet Layer Actions” gives details of the 
action taken by the DTE upon receipt of packets in each state shown tn 
Appendix B, “Packet Layer DTE/DCE Interface State Diagrams.” 


For permanent virtual circuits there is no call set-up or clearing. Procedures 
for the control of packets transferred between the DTE and DCE while in the 
Data_Transfer state (p4) are described in “Procedures for Data [and Interrupt] 
Transfer’ on page 4-6. 


> If a momentary failure occurs within the network, the DCE will reset the perma- 
> nent virtual circuit as described in § 4.4.3, with the cause “Network 
> Congestion,” and then will continue to handle data traffic. 
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If the network has a temporary inability to handle data traffic, the DCE will reset 
the permanent virtual circuit with the cause “Network Out-of-Order.” When the 
network is again able to handle data traffic, the DCE should reset the perma- 
nent virtual circuit with the cause “Network Operational.” 


Vo vo Veo 


4.3 Procedures for Data |and Interrupt] Transfer 


The data transfer [and interrupt] procedures described in this section apply 
independently to each logical channel assigned for virtual calls and permanent 
S virtual circuits existing at the DTE/DCE or DTE/DTE interface. 


Normal network operation dictates that user data in data [and interrupt] 

S packets are all passed transparently, unaltered, either directly or through the 
network in the case of packet DTE to packet DTE communications. Order of bits 
in DATA and [INTERRUPT] packets is preserved. Packet sequences are deliv- 
ered as complete packet sequences. DTE Diagnostic Codes are treated as 
described in §§ 5.2.3, 5.4.3 and 5.5.1. 


4.3.1 States for Data Transfer : 
S A virtual call logical channel is in the Flow Control Ready substate (d1) of Data. 
Transfer state (p4) after completion of call establishment and prior to a clearing 
or a restarting procedure. A permanent virtual circuit logical channel is contin- 


S ually in the Flow Control Ready substate (d1) of Data Transfer state (p4) except 
S during a reset or restart procedure. DATA, [INTERRUPT, | flow control, REJECT 
S (if subscribed to), and reset packets may be transmitted and received across 


the interface in the Data Transfer state (p4) of a logical channel. In this state, 
the flow control and reset procedures described in § 4.4 apply to data trans- 
mission on that logical channel to and from the DTE. 


When a virtual call is cleared, DATA and [INTERRUPT] packets may be dis- 
carded by the network (see § 4.5). In addition, DATA, [INTERRUPT, | flow 

S control, REJECT (if subscribed to), 
and reset packets transmitted by the DTE will be ignored by the DCE when the 
logical channel is in the DCE _CLEAR_INDICATION state (p7). Hence, it is left to 
the DTE to define DTE to DTE protocols able to cope with the various possible 
situations that may occur. 


4.3.1.1 SNA-to-SNA Connections 
Logical Link Control (LLC, see Chapter 8, “Logical Link Control (LLC) on 
SNA-to-SNA Connections”) protocols enable IBM SNA X.25 DTEs to cope with 
the various situations that may possibly occur on SNA-to-SNA connections. 


The following actions are taken by IBM SNA X.25 DTEs to protect against pos- 
sible packet losses: 
° Orderly Clearing 


Virtual call clearing is normally initiated only upon requests from SNA 
control points which are responsible for making sure that data flows have 
first been quiesced and all sessions using the virtual circuit have been 
properly deactivated. 


° Accidental Clearing 
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When call clearing is initiated by the network, following some network 
detected error condition, the station is placed in an inoperative state and 
notification of the station outage is given to a higher layer causing session 
outage notifications to be propagated according to SNA mechanisms to all 
half-sessions that were sharing the virtual circuit. Inoperative stations are 
returned to an operational state only by stimulus from a higher layer SNA 
protocol. After the station is recontacted and sessions are reestablished 
the SNA session protocols are responsible for recovery from any packet 
loss that may have occurred as a result of call clearing. 


Note: 


some early IBM SNA X.25 DTE implementations use a Physical Services 
Header (PSH - see Appendix J, “Physical Services Headers”) instead of 
the QLLC described in Appendix O, “Description of the BNN_ Qualified 
Logical Link Control - (QLLC) Procedures.” 


4.3.2 User_Data Field Length of Data Packets 


The standard maximum User _Data field length is ‘128° octets. 


In addition, other maximum User Data field lengths that may be offered by 
Administrations include: 

‘16’, 32’, ‘64’, ‘256’, 512’, ‘1024’ ‘2048’ and ‘4096’ octets. 
An optional maximum User Data field length may be selected for a period of 
time as the default maximum User Data field length common to all virtual calls 
at the interface (see § 6.9). A value other than the default may be selected for 
a period of time for each permanent virtual circuit (see § 6.9). Negotiation of 


maximum User_Data field lengths, on a per call basis, may be made with the 
Flow_Control_ Parameter Negotiation facility (see § 6.12). 


IBM SNA X.25 DTE implementations that allow maximum User Data field 
lengths other than ‘128’ octets support the Flow_Control_ Parameter Negotiation 
facility {i.e., not all networks provide the selection of a default maximum length 
other than ‘128° octets). As a result, a multi-channel interface may be required 
to simultaneously support multiple maximum packet lengths. 


The User Data field of DATA packets transmitted across the interface may 
contain any number of octets up to the agreed maximum. 


Note: 


some networks require the User Data field to contain an integral 
number of octets (see § 3.0, Note 1). 


If the User Data field in a DATA packet exceeds the locally permitted maximum 
User Data field length, then the DCE will reset the virtual call or permanent 
virtual circuit with the resetting cause “Local Procedure Error.” Upon receipt of 
a reset on a virtual call logical channel, IBM SNA X.25 DTEs clear the virtual 
call and must report the error to a higher layer. 


When IBM SNA X.25 DTEs receive DATA packets that exceed the locally per- 
mitted maximum User Data field length, they clear the virtual call or reset the 
permanent virtual circuit with appropriate Cause and Diagnostic codes (see 
Appendix H, “DTE-Generated Diagnostic Codes”) and must report the error to a 
higher layer. To be in compliance with ISO 8208 or ANS X3.100, the DTE must 
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reset the virtual call or permanent virtual circuit upon receipt of a DATA packet 
that exceeds the locally permitted maximum User Data field length. 


4.3.3 Delivery Confirmation (D) Bit 


4.3.3.1 SNA-to-SNA Connections _ 
| The value of the ‘D’ bit in packets on SNA-to-SNA connections should always be 
‘0’. When IBM SNA X.25 DTEs receive a DATA packet that contains ‘D=1’, they 
clear the virtual call or reset the permanent virtual circuit with appropriate — 
Cause and Diagnostic codes (see Appendix H, “DTE-Generated Diagnostic 
Codes”) and must report the error to a higher layer. 


Upon receipt of an INCOMING CALL or CALL_CONNECTED packet with ‘D=1’, 
IBM SNA X.25 DTEs clear the virtual call with appropriate Cause and Diagnostic 
codes (see Appendix H, “DTE-Generated Diagnostic Codes”) and report the 
error to a higher layer of SNA. 


4.3.3.2 SNA-to-non_SNA Connections 
The setting of the Delivery Confirmation bit (D-bit) is used to indicate whether or 
not the DTE wishes to receive an end-to-end acknowledgement of delivery, for 
data it is transmitting, by means of the packet receive sequence number (Pr) 
(see § 4.4). 3 


Note: 


Use of the D-bit procedure does not obviate the need for a higher layer 
protocol agreed upon between participating DTEs which may be used 
with or without the D-bit procedure to recover from user or network 
generated resets and clearings. 


The calling DTE may, during call establishment, ascertain that the D-bit proce- 
dure can be used for the call by setting bit 7 in the General Format Identifier of. 
the CALL_REQUEST packet to ‘1’ (see § 5.1.1). Every network or part of the 
international network will pass this bit transparently. If the called DTE is able to 
handle the D-bit procedure, it should not regard this bit being set to ‘1’ in the 
INCOMING CALL packet as invalid. To be in compliance to ISO 8208, if the DTE 
is unwilling to use the D-bit procedure and receives a DATA packet with the 
D-bit set to 1, then it should reset the logical channel with a cause indicating 
“DTE Originated” and the diagnostic “D_bit Procedure Not Supported.” 


Similarly, the called DTE can set bit 7 in the General Format Identifier of the 
CALL ACCEPTED packet to ‘1’. Every network or part of international network 
will pass this bit transparently. If the calling DTE is able to handle the D-bit 
procedure, it should not regard this bit being set to ‘1’ in the 

CALL CONNECTED packet as invalid. 


The use by DTEs of the above mechanism in CALL_REQUEST and 
CALL ACCEPTED packets is recommended but is not mandatory for using the 
D-bit procedure on virtual calls. 


some DTEs may request either local or remote significance and some IBM SNA 

X.25 DTEs may permit partner DTEs to operate with end-to-end significance. / 
Thus, bit 7 of the first octet (GFI) in CALL REQUEST and CALL ACCEPTED \ 
packets may be set to ‘0’ or ‘1’ according to the parameters that, in the SNA 

“BIND” command opening the SNA session corresponding to the virtual circuit, 
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indicate whether definite responses are supported for that SNA session (see 
Approach 1 in Appendix K, “SNA-to-non_ SNA Architectural Considerations”) 


Similarly, the state of bit 7 of the first octet (GFI) in INCOMING CALL packets 
may be used to determine the proper “BIND” protocol. The state of bit 7 of the 
first octet in CALL CONNECTED packets may be compared to the established 
SNA session and a decision made as to whether compatibility of operation on 
the virtual circuit and the SNA session is guaranteed. 


4.3.4 More Data Mark | 
lf a DTE or DCE wishes to indicate a sequence of more than one packet, it uses 
a More Data mark (M-bit) as defined below. 


4.3.4.1 SNA-to-SNA Connections 
M-bit segmenting is required for IBM SNA X.25 DTEs, but if compatibility with 
the IBM 5973 NIA is required, the PSH segmenting procedure described tn 
Appendix J, “Physical Services Headers” must be implemented as well. 


When PSH segmenting is implemented, the maximum packet size must be the 
Same at the local and remote X.25 DTE/DCE interfaces. 


‘M= 1’ is only used in full data packets to indicate that more data follows. 
Recombination with the following data packet may only be performed within the 
network when ‘M=1. 


Upon receipt of a partially filled DATA packet with ‘M = 1’, IBM SNA X.25 DTEs 
on SNA-to-SNA connections clear the virtual call or reset the permanent virtual 
circult with appropriate Cause and Diagnostic codes (see Appendix H, 
“DTE-Generated Diagnostic Codes”). 


4.3.4.2 SNA-to-non_ SNA Connections 
The M-bit can be set to ‘1’ in any DATA packet except in a partially full DATA. 
packet carrying the D-bit set to zero. ‘M= 1’ in a full DATA packet or in a par- 
tially full DATA packet that also has ‘D=1’, indicates that more data follows. 
Recombination with the following DATA packet may only be performed within 
the network when ‘M=1’ in a full DATA packet that also has ‘D=0’. 


A sequence of DATA packets with ‘M = 1’ in every packet except for the last 
one will be delivered as a sequence of DATA packets with ‘M=1’ in every 
packet except for the last one when the original packets having ‘M=1’ are 
either full (irrespective of the setting of the D-bit) or partially full but have 
‘D=1’. 


Two categories of data packets, ‘A’ and ‘B’, are defined as shown in Table 15. 
Table 15 also illustrates the network’s treatment of the M-bit and the D-bit at 
both ends of virtual calls or permanent virtual circuits. A DTE should not 
transmit a partially full DATA packet with the M-bit set to 1 and the D-bit set to 
0. Upon receipt of such a packet, the DTE (even if acting as a DCE ina 
DTE/DTE environment) should reset the logical channel. 
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Table 15: Definition of Two Categories of DATA Packets and Network 
Treatment of the M-bit and the D-bit 


Data Packet* 
Received by 
Destination DIE 


Combining with 
subsequent packet(s) 
is performed by 
the network 
when possible 


Data packet sent 
by source DIE 


* — Refers to the delivered data packet whose last bit of user data 
corresponds to the last bit of user data, if any, that was 
present in the data packet sent by the source DTE. 

* — Valid on SNA-to-non_ SNA connections only. 


Notes with reference to Table 15: 
1. The originating network will force the M-bit to ‘0’. 


2. If the DATA packet sent by the source DTE is combined with other packets, 
up to and including a category ‘B’ packet, the M-bit and the D-bit settings in 
the DATA packet received by the destination DTE will be according to that 
given in the right hand columns for the last DATA packet sent by the source 
DTE that was part of the combination. 


4.3.5 Complete Packet Sequence 
A complete packet sequence is defined as being composed of a single category 
‘B’ packet and all contiguous preceding category ‘A’ packets (if any). Category 
‘A’ packets have the exact maximum User _Data field length with (M=1° and 
‘D=0’. All other DATA packets are category ‘B’ packets. 


When transmitted by a source DTE, a complete packet sequence is always 
delivered to the destination DTE as single complete packet sequence. 


Thus, if the receiving end has a larger maximum User Data field length than 
the transmitting end, then packets within a complete packet sequence will be 
combined within the network. They will be delivered in a complete packet 
sequences where each packet, except the last one, has the exact maximum 
User Data field length, ‘M=1' and ‘D=0’. The User Data field of the last 
packet of the sequence may have less than the maximum length and the M- bit 
and the D-bit set as described in Table 195. 
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If the maximum User Data field length is the same at both ends, then 

User Data fields of DATA packets are delivered to the receiving DTE exactly as 
received by the network, except as follows. Ifa full packet with (M=1’ and 
‘D=0' is followed by an empty packet, the two packets may be merged so as to 
become a Single category ‘B’ full packet. If the last packet of a complete packet 
sequence transmitted by the source DTE has a User Data field less than the 
maximum length with ‘M = 1° and ‘D = 0’ (which a DTE is not permitted to 
send), the last packet of the complete packet sequence is delivered to the desti- 
nation DTE with ‘M=0O. | 


If the receiving end has a smaller maximum User Data field length than the 
transmitting end, the packets will be segmented within the network, and the 
M-bit and the D-bit set by the network as described to maintain complete 
packet sequences. | 


4.3.5.1 SNA-to-SNA Connections Only 
When PSH segmenting is used, the maximum packet length at the local and 
remote DTE/DCE interfaces is the same. Therefore, no ‘M’ bit packet 
sequences occur at either DTE/DCE interface. 


4.3.6 Qualifier Bit 
In some cases, an indicator may be needed with the User Data field to distin- 
guish between two types of information. It may be necessary to differentiate, 
for example, between User Data and control information. An example of such 
a case is contained in CCITT Recommendation X.29. 


If such a mechanism is needed, an indicator in the DATA packet header, called 
the Qualifier bit (Q-bit), may be used. 


The use of the Q-bit is optional. If this mechanism is not needed, the Q-bit is 
always set to ‘0’. If the Q-bit mechanism is used, the transmitting DTE should 
set the Q-bit so as to have the same value ({i.e., ‘0’ or ‘1’) in all DATA packets of 
the same complete packet sequence. The setting of the Q-bit in a complete 
packet sequence is determined from instructions received from a higher layer 
entity. Likewise, the setting of the Q-bit for each complete packet sequence 
received is passed to a higher layer entity. A complete packet sequence trans- 
ferred by the DTE to the DCE in this fashion will be delivered to the distant DTE 
as a complete packet sequence having the Q-bit set in all packets to the value 
assigned by the transmitting DTE. 


If the Q-bit is not set by the DTE to the same value in all the DATA packets of a 
complete packet sequence, the value of the Q-bit in any of the DATA packets of 
the corresponding packet sequence transferred to the distant DTE is not guar- 
anteed by the network. Moreover, some networks may reset the virtual call or 
permanent virtual circuit as described in Appendix C, “Packet Layer DCE 
Actions.” 


Other sequences of Q-bit settings received cause IBM SNA X.25 DTEs to reset 
the permanent virtual circuit or clear the virtual call with appropriate Cause and 
Diagnostic codes {see Appendix H, “DTE-Generated Diagnostic Codes”). IBM 
SNA X.25 DTEs must report the contents of the resetting/clearing cause and 
diagnostic code fields to a higher layer. To be in compliance with ISO 8208, the 
action taken by a DTE when the Q-bit is not set to the same value in all DATA 
packets received in a complete packet sequence is to reset the logical channel 
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with a cause indicating “DTE Originated” and the diagnostic “Inconsistent Q-bit 
Settings”. 


Successive DATA packets are numbered consecutively (see § 4.4.1.1) regard- 
less of the value of the Q-bit. 


4.3.6.1 SNA-to-SNA Connections 
The Q-bit is used by IBM SNA X.25 DTEs on SNA-to-SNA connections to identify 
DATA packets associated with the QLLC procedure described in § 8.0. 


4.3.6.2 SNA-to-non_SNA Connections 
CCITT Recommendation X.29 provides one example of the procedures to be 
used when the Q-bit is set to ‘1’. IBM SNA X.25 DTEs that support CCITT 
Recommendation X.29 and other packet assembly/disassembly (PAD) control 
procedures implement the Q-bit procedure, accordingly. 


4.3.7 Interrupt Procedure 


4.3.7.1 SNA-to-SNA Connections 
The interrupt procedure is not permitted on SNA-to-SNA connections. IBM SNA 
X.29 DTEs clear the virtual call or reset the permanent virtual circuit with the 
Diagnostic, “Not Supported,” #170 (x‘AA’) upon réceipt of a DCE_INTERRUPT or 
DCE_ INTERRUPT CONFIRMATION packet. 


4.3./.2 SNA-to-non_SNA Connection 
The interrupt procedure allows a DTE to transmit data to the remote DTE, 
without following the flow control procedures applying to DATA packets (see § 
4.4). The initiation of the interrupt procedure and the generation of the data are 
controlled by a higher layer entity. Upon receipt of an INTERRUPT packet, a 
Signal indicating that an interrupt has occurred, along with the data, is passed 
to a higher layer entity. The interrupt procedure can only apply during the 
Flow_Control_ Ready state (d1) within the Data_Transfer state (p4). Therefore, 
the interrupt procedure is abandoned as a result of a clearing (Virtual Calls 
only), reset, or restart procedure. Within state d1, there are four states (two for 
each direction of interrupt transmission) that apply to the interrupt procedure. 
They are the DTE_Interrupt_Ready (i1), DTE_Interrupt_Sent (i2), DCE/remote 
DTE Interrupt Ready (j1), DCE/remote DTE Interrupt_Sent (j2) states. Table I-5 
specifies the action taken by the DTE on the receipt of interrupt packets from 
the DCE/remote DTE as applied to the interrupt procedure. 


The interrupt procedures have no effect on the transfer and flow control proce- 
dures applying to the DATA packets on the virtual call or permanent virtual 
circuit. For a given Virtual Call or Permanent Virtual Circuit, an INTERRUPT 
packet is delivered at or before the point in the stream of DATA packets at 
which the interrupt was generated. It must be processed as soon as It is 
received. | 


An INTERRUPT packet may contain up to 32 octets of user data. Ifthe 
User Data Field in an INTERRUPT packet exceeds 32 octets or if it is nonectet 
aligned, then the receiving DTE will invoke the reset procedure. 


Prior to transmitting an interrupt, the logical channel is in the 


DTE_ Interrupt Ready state (i1). To transmit an interrupt, a DTE transfers a 
DTE INTERRUPT packet across the interface and starts the Interrupt Response 


4-12 Architecture Reference 


nA ANA NAM 


Fn aAanennAa wm ™ 


nnn DP 


VVVV VY 


Timer (T26). At this time, the logical channel is in the DTE_Interrupt_Sent state 
(i2). Failure to receive an INTERRUPT CONFIRMATION packet before expiration 
of T26 after transmission of an INTERRUPT packet is considered an error. In 
this case, the DTE resets the logical channel with a cause indicating “DTE Origi- 
nated and the diagnostic “Timer Expired for Interrupt.” The DTE should not 
transmit a second DTE_INTERRUPT packet until the first one is confirmed with a 
DCE_INTERRUPT CONFIRMATION packet (see Table C-4). The DCE, after the 
interrupt procedure is completed at the remote end, will confirm receipt of the 
interrupt by transferring DCE_INTERRUPT CONFIRMATION packet. Receipt of a 
DCE_INTERRUPT CONFIRMATION packet indicates that the interrupt has been 
confirmed by the remote DTE by means of a DTE_INTERRUPT_ CONFIRMATION 
packet. 


The DCE indicates an interrupt from remote DTE by transferring 
DCE_INTERRUPT packet containing the same DATA field as in the 

DTE_ INTERRUPT packet transmitted at the remote DTE. The DTE will confirm 
receipt of the DCE_INTERRUPT packet by transferring a 

DTE INTERRUPT CONFIRMATION packet. 


Prior to receiving an interrupt, the logical channel is in the DCE/remote 

DTE Interrupt Ready state (j1). When a DTE receives an INTERRUPT packet 
from the DCE/remote DTE, the logical channel is in the DCE/remote 

DTE_ Interrupt Sent state (j2). In this state, receipt of a subsequent INTERRUPT 
packet before confirming the prior INTERRUPT packet is considered an error. 

In this case, the DTE resets the nOgiea channel with a cause indicating “DTE 
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Origindied” and ine diagnostic “Unauthorized interrupt.” 


The Packet Layer passes an indication of the interrupt and the Interrupt 
User Data to a higher iayer entity. 


A DTE confirms receipt of an INTERRUPT packet as soon as possible by trans- 
mitting across the interface an INTERRUPT CONFIRMATION packet. At this 
time, the logical channel is in the DTE/remote DTE_Interrupt Ready state (j1). 


When a DTE, having previously transmitted an INTERRUPT packet, receives an 
INTERRUPT CONFIRMATION packet, the logical channel ts in the 

DTE Interrupt Ready state {i1). At this time, the DTE may transmit a subse- 
quent INTERRUPT packet across the interface. 


4.3.8 Transit Delay of DATA Packets 


Transit delay is an inherent characteristic of a virtual call or a permanent 
virtual circuit, common to the two directions of transmission. 


This transit delay is the data packet transfer delay as defined in § 3.1 of Recom- 
mendation X.135, measured between boundaries B2 and Bn-1, as defined in 
Figure 2 of Recommendation X.135 (that means, excluding the access lines), 
with the conditions given in § 3.2 of CCITT Recommendation X.135, and is 
expressed in terms of a mean value. 


selection of transit delay on a per call basis, and indication to both the calling 
and called DTEs of the value of transit delay applying for a given virtual call, 
may be made by the means of the transit delay selection and Indication facility 
(see § 6.28). 
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4.3.9 Fragmentation and F 
The Packet Layer provides the service of transmitting messages (also referred 
to as M-bit sequences) between peer higher layer entities. In a source DTE, the 
Packet Layer fragments (i.e., packetizes) a message into the appropriate 
number of DATA packets and sets the D-bit, M-bit, and Q-bit for each resulting 
packet. This process must take into account the maximum User_Data Field 
length allowed for the logical channel, the length and Q-bit setting for each 
complete packet sequence contained in the message, and whether end-to-end 
acknowledgement is requested, then the D-bit is set to 1 in the last DATA 
packet of the message. {The D-bit is used only on a SNA-to-non SNA con- 
nection.) | 
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S Note: 


S It is permissible to fragment a message in such a way that results in a 
+ DATA packet containing a User Data Field of zero length, however, it is 
ae recommended that IBM DTEs not transmit such packets. 


4.4 Procedures for Flow Control 


This section (§ 4.4) only applies to the Data_Transfer state (p4) and specifies the 
procedures covering flow control of DATA packets and reset packets on each 
logical channel used for a virtual call or permanent virtual circuit. The flow 
control procedure can apply only in the Fiow_Control_ Ready state (d1). There- 
fore, the flow control procedure is abandoned as a result of a clearing (Virtual 
Calls only), reset, or restart procedure. Within state d1, there are four states 
(two for each direction of flow control) that apply to the flow control procedure. 
They are the DCE Receive Ready (f1), DCE Receive _Not_Ready (f2), 

DTE_ Receive Ready (g1), and DTE_Receive_Not_Ready (g2) states. Table I-6 
specifies the action taken by the DTE on the receipt of flow control, DATA, and 
REJECT (if subscribed to) packets as applied to the flow control procedure. 
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S The flow control procedure has no effect on the procedures applying to INTER- | 
S RUPT packets on a Virtual Call or Permanent Virtual Circuit. 


4.4.1 Flow Control 
At the DTE/DCE or DTE/DTE interface of a logical channel used for a virtual call 
or permanent virtual circuit, the transmission of DATA packets is controlled 
separately for each direction of transmission and is based on authorizations 
from the receiver. | 


On a virtual call or permanent virtual circuit, flow control also allows a DTE to 
limit the rate at which it accepts packets across the interface, noting that there 
is a network-dependent limit on the number of DATA packets that can be in the 
network on the virtual call or permanent virtual circuit. 


4.4.1.1 Numbering of Data Packets 
Each DATA packet transmitted across the interface for each direction of trans- 
mission on a virtual call or permanent virtual circuit is sequentially numbered. 


The sequence numbering scheme of the packets is performed modulo ‘8’. The 
packet sequence numbers cycle through the entire range ‘0’ to ‘7’, inclusively. 
Some Administrations provide the Extended_Packet_Sequence_Numbering 
facility (see § 6.2) which, if selected, provides a sequence numbering scheme 
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for packets being performed modulo ‘128’. In this case, packet sequence 
numbers cycle through the entire range ‘0’ to ‘127’, inclusively. The packet 
sequence numbering scheme, modulo ‘8’ or ‘128’, is the same for both 
directions of transmission and applies for all logical channels at the interface. 


Note: 


All IBM SNA X.25 DTEs must implement Modulo ‘8’ packet 
sequence numbering. Implementation of modulo ‘128’ packet 
sequence numbering is a product option. 


Only DATA packets contain this sequence number called the packet send 
sequence number, Ps. 


The first DATA packet transmitted across the interface for a given direc- 

tion of data transmission, when the logical channel has just entered the 
S Flow _Control_ Ready state (d1), has ‘Ps=0’. Subsequent DATA packets 
S are numbered consecutively. 


4.4.1.2 Window Description 
S At the DTE/DCE or DTE/DTE interface, a window is defined for each direc- 
tion of data transmission, of a logical channel! used for a virtual call or 
permanent virtual circuit. The window is the ordered set of ‘W’ consec- 
utive packet send sequence numbers of the DATA packets authorized to 
cross the interface. 


The lowest sequence number in the window is referred to as the lower 
window edge. When a virtual call or permanent virtual circuit at the 
interface has just entered the Flow_Control_ Ready state (d1), the window 
related to each direction of data transmission has a lower window edge 
equal to ‘0. 


The Ps of the first DATA packet not authorized to cross the interface is the 
value of the lower window edge plus ‘W’ (modulo ‘8’, or ‘128’ when 
extended). 


The standard window size, ‘W’, is two (2) for each direction of data trans- 
mission at the DTE/DCE interface. In addition, other window sizes may be 
offered by Administrations. An optional window size may be selected for 
a period of time as the default window size common to all virtual calls at 
the interface (see § 6.10). A value other than the default may be selected 
for a period of time for each permanent virtual circuit (see § 6.10). Negoti- 
ation of window sizes, on a per call basis, may be made with the 
Flow_Control_ Parameter Negotiation facility (see § 6.12). 


All IBM SNA X.25 DTEs must implement ‘W = 2’ and also allow values 
other than ‘W = 2’, namely, ‘W < modulus’ to be set as determined at 
subscription time. When the access link to the network exhibits long 
delay characteristics and the packets used are short, IBM SNA X.25 DTEs 
may implement the optional Flow_Control_Parameter_Negotiation facility 
as not all networks permit selection of default values other than ‘W = 2’. 
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4.41.3 Flow Control Principles 
When the Ps of the next DATA packet to be transmitted by the station 
(DTE or DCE) is within the window, the station is authorized to transmit 
this DATA packet to the remote station. When the Ps of the next data 
packet to be transmitted is outside of the window the station will not 
transmit a DATA packet to the remote station. The remote station should 
follow the same procedure. 


When the Ps of the DATA packet received by the station is the next in- 
sequence and is within the window, the station will accept the DATA 
packet. A received DATA packet containing a Ps that is out of sequence 
{i.e., there is a duplicate or a gap in the Ps numbering), outside the 
window or not equal to ‘0’ for the first DATA packet received after entering 
the Flow_Control_ Ready state (d1) is considered by the station to be a 
local procedure error. In a DTE/DCE environment, a DCE will reset the 
logical channel (see § 4.4.3) with a cause indicating “Local Procedure 
Error’. A DTE will reset the logical channel with a cause indicating 
“DTE-Originated”. In either case, the diagnostic will be “Invalid Ps.” IBM 
SNA X.25 DTEs must report the resetting Cause and Diagnostic Code to a 
higher layer. Because packets should never get out of order on 
SNA-to-SNA connections (packet layer retransmission does not occur), an 
out-of-sequence Ps should be treated as an error. 


A number modulo ‘8’ (or ‘128’ when extended), referred to as a packet 
receive sequence number (Pr), conveys across the interface information 
from the receiver for the transmission of DATA packets. When transmitted 
across the interface a Pr becomes the lower window edge. In this way, 
additional DATA packets are authorized by the receiver to cross the inter- 
face. 


The Pr is conveyed in DATA, RECEIVE READY (RR), RECEIVE NOT READY 
(RNR), and REJECT (if subscribed to) packets. 


The value of a Pr received must be within the range from the last Pr 
received by the station up to and including the Ps of the next DATA packet 
to be transmitted by the station. Otherwise, the station will consider the 
receipt of this Pr as a procedure error and reset the virtual call or perma- 
nent virtual circuit. IBM SNA X.25 DTEs consider the receipt of a Pr value 
that is not within the range from the last Pr received up to and including 
the Ps of the next DATA packet to be transmitted as a DCE failure and 
reset the virtual circuit with appropriate Cause and Diagnostic codes (see 
Appendix H, “DTE-Generated Diagnostic Codes”). 


The Pr is less than or equal to the sequence number of the next expected 
DATA packet and implies that the DTE or DCE transmitting the Pr has 
accepted at least all DATA packets. numbered up to and including ‘Pr-1’. 


4.4.1.4 Delivery Confirmation 
When ‘D = 0’ in a DATA packet having ‘Psp’, the significance of the 
returned Pr corresponding to that DATA packet (1.e., ‘Pr>p + 1)isa 
local updating of the window across the packet layer interface so that the 
achievable throughput is not constrained by the round- me DTE-to-DTE 
delay across the network ({s). 
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In a DTE/DCE environment, when ‘D = 0’ in a DATA packet, the returned 
Pr corresponding to that DATA packet does not signify that a Pr has been 
received by the remote DTE. 


1. SNA-to-SNA Connections 


‘D = 1’ is not allowed on SNA-to-SNA connections. If a packet 
with ‘D = 1’ is received on an SNA-to-SNA connection, IBM SNA 
X.25 DTEs clear the virtual call or reset the permanent virtual 
circuit with appropriate Cause and Diagnostic codes (see 
Appendix H, “DTE-Generated Diagnostic Codes”). 


If an INCOMING CALL or CALL_CONNECTED packet ts received 
with bit 7=‘1', IBM SNA X.25 DTEs clear the call with appropriate 
Cause and Diagnostic codes (see Appendix H, “DTE-Generated 
Diagnostic Codes”). In any case, the error condition and Cause 
and Diagnostic codes must be reported to a higher layer. 


2. SNA-to-non SNA Connections 


When ‘D = 1’ in a DATA packet having ‘Ps=p’, the significance of 
the returned Pr corresponding to that DATA packet (i.e., ‘Pr >p + 
1’) is an indication that a Pr has been received from the remote 
DTE for all data bits in the DATA packet which originally had ‘D = 
a he 


Notes: 


a. To achieve a greater degree of reliability, DTES may use 
ihe D-bit procedure to signify receipt of data by a higher 
layer entity. Such use requires prior agreement between 
the two DTEs. When using this procedure, the sending 
Packet Layer sets the D-bit of the last DATA packet in an 
M-bit sequence to 1 if end-to-end receipt confirmation by a 
higher layer entity is desired. On receiving the last DATA 
packet of an M-bit sequence with ‘D = 1’, the Packet 
Layer must not return the corresponding Pr until the data 
in this packet has been acknowledged by a higher layer 
entity. When this acknowledgement is received, the 
Packet Layer should return this Pr as soon as possible 
(e.g., without waiting for further DATA packets) to avoid — 
the possibility of deadlocks. A DATA, RR, RNR, or REJECT 
(if subscribed to) packet may be used to convey the Pr 
(see note to § 4.4.1.6). Likewise, in a network environ- 
ment, the DCE is required to send Pr to the DTE as soon 
as possible after the Pr is received from the remote DTE. 


b. If a Pr for a DATA packet with ‘D = 1’ is outstanding, local 
updating of the window will be deferred for subsequent 
DATA packets with ‘D = 0’. Some networks may also 
defer updating the window for previous DATA packets 
(within the window) with ‘D = 0’ until the corresponding Pr 
for the packet with the outstanding ‘D = 1’ is transmitted 
to the DTE. 


c. Pr values corresponding to the data contained in DATA 
packets with the ‘D=1' need not be the same at the 
DTE/DCE interfaces at each end of a virtual call or perma- 
nent virtual circuit. 
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d. If the DTE has sent DATA packets with ‘D = 0’, the DTE 
does not have to wait for local updating of the window by 
the DCE before initiating a resetting or clearing procedure. 


e. When the DTE is unwilling to use the D-bit procedure and 
receives a DATA packet with ‘D = 1’, then it should reset 
the logical channel with a cause indicating | 
“DTE-Originated” and the diagnostic “D-bit Procedure Not. 
Supported.” 


If the virtual call has not been established indicating support of 
the D-bit procedure, IBM SNA X.25 DTEs do not send DATA 
packets with ‘D = 1°. If they receive a packet with ‘D = 1’ 
from a non-SNA DTE they clear the virtual call or reset the 
permanent virtual circuit with appropriate Cause and Diag- 
nostic codes (see Appendix H, “DTE-Generated Diagnostic 
Codes’). 


To be in compliance with ANS X3.100: 
e The D-bit procedure shall be implemented by all networks. 


e DTEs need not employ the D-bit procedures when transmit- 
ting to the network, but no DTE shall reject incoming 
packets with the D-bit set to ‘1’ or ‘0’ as having this bit in 
error, unless the receiving DTE knows the remote DTE has 
not implemented this value of the D-bit; in this case, the 
receiving DTE may treat such an occurrence as an error 
condition. Specifically, if this error condition applies and 
the packet received is acceptable to the state of the logical 
channel, then the DTE invokes the error procedure with 
diagnostic “D-bit Procedure Not Supported” 


4.41.5 DTE and DCE RECEIVE READY (RR) Packets 


RR packets are used by the DTE or the DCE to indicate that it is ready to 
receive the ‘W’ DATA packets within the window starting with Pr, where Pr 
is indicated in the RR packet. 


4.41.6 DTE and DCE RECEIVE NOT_READY (RNR) Packets 


RNR packets are used by the DTE or the DCE to indicate a temporary ina- 
bility to accept additional DATA packets for a given virtual call or perma- 
nent virtual circuit. A DTE or DCE receiving an RNR packet shall stop 
transmitting DATA packets on the indicated logical channel, but the 
window is updated by the Pr value of the RNR packet. The receive not 
ready situation indicated by the transmission of an RNR packet is cleared 
by the transmission in the same direction of an RR or REJECT (if sub- 
scribed to) packet or by initiation of a resetting procedure. 


The transmission of an RR packet after an RNR packet at the packet layer 
is not to be taken as a demand for retransmission of packets which have 
already been transmitted. 


Note: 


The RNR packet may be used to convey across the DTE/DCE inter- 
face the Pr value corresponding to the DATA packet which had ‘D 

= 1’ in the case that additional DATA packets cannot be accepted 
on SNA-to-non_SNA connections. 
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4.4.2 Throughput Characteristics and Classes 
> The definition of throughput and steady state throughput are given in § 4 
> of CCITT Recommendation X.135. 


A throughput class for one direction of transmission ts an inherent charac- 
teristic of the virtual call or permanent virtual circult related to the amount 


> of resources allocated to this virtual call or permanent virtual circuit. It is 
> a measure of the steady state throughput that can be provided under 
> optimal conditions on a virtual call or permanent virtual circuit. However, 


due to the statistical sharing of transmission and switching resources, It Is 
not guaranteed that the throughput class can be reached 100% of the 
time. 


The relationship between throughput class and the throughput parameters 
and objectives described in CCITT Recommendation X.135 require further 
study. The complete definition of the optimal conditions where the 
measure of the steady state throughput in relation to throughput class is 
meaningful also requires further study. Pending the results of these 
further studies, it cannot be guaranteed or verified that a network sup- 
porting a given throughput class value (64K bit/s for instance) offers better 
performance to its users than a network not supporting that throughput 
class. However, a network may offer a guarantee to its users on a con- 
tractual basis. 


VVVVVVVVV YV 
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The optimal conditions per measurement include the following: 


e Access line characteristics of the local and remote DTEs do not 
constrain the throughput ciass; 


VV 


V 


Note: 


In particular, because of the overhead due to the frame 
and packet headers, when the throughput class corre- 
Sponding to the user class of service of the DTE is appli- 
cable to a virtual call or permanent virtual circuit, a steady 
State throughput equal to that throughput class can never 
be reached. 


« Window sizes at the local and remote DTE/DCE interfaces do not 
constrain the throughput; 
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Traffic characteristics of other logical channels at local and remote 
DTE/DCE interfaces do not constrain the throughput; 


VV 


¢ Receiving DTE is not flow controlling the DCE such that the 
throughput class is not attainable; 


e Transmitting DTE sends only DATA packets which have the 
maximum data field length; and, 


© ‘D = 0’. 
> The throughput class is expressed in bits per second. The maximum 
User Data field length is specified for a virtual call or permanent virtual 


circuit, and thus the throughput class can be interpreted by the DTE as the 
> number of full DATA packets/second at the DTE/DCE interface. 
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In the absence of the Default_Throughput_Class_Assignment facility (see § 
_ 6.11), the default throughput classes for both directions of transmission 
correspond to the user class of service of the DTE (see § 7.2.2.2) but do 
not exceed the maximum throughput class supported by the network. 
_ Negotiation of throughput classes on a per call basis may be made with 
the Throughput Class Negotiation facility (see § 6.13). 


Note: 


The sum of throughput classes of all virtual calls and permanent 
virtual circuits supported at a DTE/DCE interface may be greater 
than the data transmission rate of the access line. 


4.4.3 Procedure for Reset | —— 
S The reset procedures described in this section apply independently to 
S each logical channel. 


The reset procedure is used to re-initialize virtual call or permanent 


S Virtual circuit. When a Virtual Call or Permanent Virtual Circuit has just 
S been reset, the following actions relative to the logical channel are taken. 
S | °e With respect to DATA packets: 


— those that have been transmitted are removed from the 
S | window, | 


S | — those that have not been transmitted but are contained in an 
S 7 M-bit sequence for which some DATA packets were trans- 

S | mitted are flushed from the queue of DATA packets awaiting 
S transmission, and 


S — those that have been received but which do not constitute an 
S entire M-bit sequence are flushed from the M-bit sequence 

S reassembly area (as an alternative, these packets may be 

S passed to a higher layer entity with an indication that they do 
S not constitute an entire M-bit sequence). 


S | | e The lower window edge for each direction of data transmission is 
| set to 0 and subsequently transmitted DATA packets are num- | 
5 | | bered starting from 0. | ( 
S | | e Any receive-not-ready condition that had existed prior to the reset 
S | is considered not to exist any longer. 
S e All timer and retransmission parameters relating to data and inter- 
S | | _ rupt transfer are set back to their initial value (these include 124, 
S T25, T26, T27, R25, and R27). 
S In network applications, the reset procedure removes in each direction all 
S | DATA, INTERRUPT, and flow control packets that may be in the network 
S associated with that logical channel. 
S —— The reset procedure can only apply in the Data_Transfer state (p4). In any 
S other state, the reset procedure is abandoned. For example, when a 


clearing or restarting procedure is initiated, RESET REQUEST and 
~ RESET_INDICATION packets can be left unconfirmed. i 


For flow control, there are three states d1, d2, and d3 within the 
Data_Transfer state (p4). They are Flow _Control_ Ready (d’1), 
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DTE Reset_Request (d2), and DCE Reset_Indication (d3) as shown in the 
state diagram in Figure B-3. When entering state p4, the logical channel 
is placed in state d1. Table C-4 specifies actions taken by DCEs on 
receipt of packets from the DTE. Appendix I, “Description of DTE Packet 
Layer Actions” specifies actions taken by DTEs upon receipt of packets 
from DCEs. 


4.4.3.1 Reset Request Packet 


The DTE indicates a request for reset at any time by transmitting a 
RESET REQUEST packet specifying the logical channel to be reset and by 
Starting the Reset Request Response Timer (T22). This places the logical 
channel in the DTE Reset Request state (d2). DTEs discard DATA, 
[INTERRUPT,] RR, and RNR packets received on logical channels in the 
DTE Reset Request state. Packets of incomplete packet sequences, 
received in this state, are also discarded. 


A diagnostic code as defined in Appendix H, “DTE-Generated Diagnostic 
Codes” must be included. Error conditions that cause a reset must be 
reported, with associated diagnostic codes, to a higher layer of SNA. 


The failure to receive a RESET CONFIRMATION packet before the expira- 
tion of T22 after transmission of a RESET REQUEST packet is considered 
an error. The reset procedure is retried up to a maximum number of 
times R22. After this, for a Virtual Call logical channel, the Packet Layer 
clears the call with a cause indicating “DTE-Originated” and a diagnostic 
“Timer Expired Or Retransmission Count Surpassed For Reset Request.” 
For a Permanent Virtual Circuit logical channel, the Packet Layer notifies 
the appropriate entity; the logical channel then remains in the 

DTE Reset_Request state (d2). 


4.4.3.2 Reset Indication Packet 


The DCE will indicate a reset by transmitting to the DTE a 

RESET INDICATION packet, specifying the logical channel being reset and 
the reason for the resetting. This places the specified logical channel in 
the DCE_Reset_Indication state (d3). In this state, the DCE will ignore 
DATA, LINTERRUPT,] DTE_RNR and DTE_RR packets. In this state, the 
DTE considers subsequent receipt of any DATA, INTERRUPT, 

RECEIVE READY, or RECEIVE_NOT_ READY packets as an error. It dis- 
cards any such packet and transmits a RESET REQUEST packet with a 
cause indicating “DTE-Originated” and the diagnostic “Packet Type Invalid 
for State d3”. DTEs discard untransmitted packets of send packet 
sequences and notify a higher layer of the inoperative condition, reporting 
the resetting cause and diagnostic codes. 


In a DTE/DTE environment, the RESET INDICATION packet received by 
one DTE is the same as the RESET REQUEST packet transmitted by the 
other DTE. 


In a DTE/DCE environment, RESET INDICATION packets are used as a 
normal sequence for packet layer initialization, e.g.: 


e A RESET INDICATION packet with Cause “Out-of-Order (x‘01’)” is 
returnea by the X.25-based network to indicate that the remote 
DTE/DCE interface has not, as yet, been initialized. 
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e A RESET INDICATION packet with Cause, “DTE-Originated (x‘00’)” 
and the Diagnostic, “PU Not Available” #197 (x‘C6’) is returned by 
an SNA NIA to indicate that the SNA SDLC link has not, as yet, 
been initialized. 


e RESET INDICATION packets with Cause, “Remote DTE 
Operational” (x‘09’)” are propagated by X.25-based networks for 
each permanent virtual circuit as a result of a restarting procedure 
at the remote DTE/DCE interface. 


e A RESET INDICATION packet with cause “Network Congestion” 
will be received from the DCE if a momentary failure occurs within 
the network. 


e A RESET INDICATION packet with cause “Network Out of Order” 
will be received from the DCE if a network has a temporary ina- 
bility to handle data traffic. 


¢« In the previous situation, a RESET_INDICATION Packet with cause 
“Network Operational” will be received from the DCE on a Perma- 
nent Virtual Circuit when the network can handle data traffic again. 


After processing the RESET INDICATION packet, the DTE transmits a 
RESET CONFIRMATION packet across the interface. 


4.4.3.3 Reset Collision 
Reset collision occurs when a DTE and a DCE simultaneously transmit a 
RESET REQUEST packet and a RESET_INDICATION packet specifying the 
same logical channel. In this event the DCE and the DTE will consider 
that the reset is complete. The DCE will not expect a 
DTE RESET CONFIRMATION packet and will not transfer a 
DCE RESET CONFIRMATION packet. DTEs do not expect a 
DCE RESET CONFIRMATION packet and do not transfer a 
DTE RESET CONFIRMATION packet when a reset collision occurs. This 
places the specified logical channel in the Flow_Control_ Ready state (d’‘1). 


4.4.3.4 Reset Confirmation Packets 
When a logical channel is in the DTE_Reset_ Request state (d2), the DCE 
will confirm the reset by transmitting a DCE RESET CONFIRMATION 
packet. 


In a network environment, the DCE_RESET CONFIRMATION packet can 
only be interpreted universally as having local significance; however, 
within some Administrations’ networks, reset confirmation may have end- 
to-end significance. In all cases the time spent in the DTE_Reset_Request 
State (d2) will not exceed time-limit T22 (see Appendix D, “DCE Time-outs 
and DTE Time-limits” on page D-‘). 


When the logical channel is in the DCE_Reset_Indication state (d3), the 
DTE will confirm the reset by transmitting a DTE_RESET CONFIRMATION 
packet before time T12 elapses. This places the logical channel in the 
Flow_Control_ Ready state {(d1). The action taken by the DCE when the 
DTE does not confirm the reset within time-out T12 are given in 
Appendix D, “DCE Time-outs and DTE Time-limits” on page D-1. 
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4.5 Effects of Clear, Reset and Restart Procedures on the 
Transfer of Packets 


All DATA [and INTERRUPT] packets generated by a DTE (or the network) 
os before initiation by the DCE or the DTE of a clear, reset or restart proce- 
dure at the local interface will either: 


¢ be delivered to the remote DTE before the DCE transmits the cor- 
responding indication on the remote interface, or 
e be discarded by the network. 


No DATA [or INTERRUPT] packets generated by a DTE (or the network) 
after completion of a reset (or for permanent virtual circuits also a restart) 
procedure at the local interface will be delivered to the remote DTE before 
completion of the corresponding reset procedure at the remote interface. 


When a DTE initiates a clear, reset or restart procedure on its local inter- 
face, all DATA and [INTERRUPT] packets which were generated by the 
remote DTE (or the network) before the corresponding indication is trans- 
mitted to the remote DTE will either: 


e be delivered to the initiating DTE before DCE confirmation of the 
initial clear, reset or restart request, or 
e be discarded by the network. 


Note: 


The maximum number of packets that may be discarded, by the 
network as a result of a clear, reset or restarting procedure, is a 
function of: 


e network end-to-end delay and 
e throughput characteristics 
and, in general, has no relation to the local window size. 


4.5.1 SNA-to-non_SNA Connections 
[For virtual calls and permanent virtual circuits on which all DATA packets 
are transferred with ‘D=1’, the maximum number of packets that may be 
discarded in one direction of transmission is never larger than the window 
size for the direction of transmission]. 


+ 4.6 Effects of the Physical and Data Link Layer on the Packet 
+ Layer 


> 4.6.1 General principles 


> In general, if a problem detected in a layer (physical, data link or packet 
> layer) can be resolved in this layer according to the DCE error recovery 
2 procedures provided in this specification without loss or duplication of 

> data, the adjacent layers are not involved in recovery. 

> If error recovery by the DCE implies a possible loss or duplication of data, 
> the higher layer is informed. 
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Reinitialization of a layer by the DCE is only performed if a problem 
cannot be resolved in that layer. 


V 


> Changes of operational states of the physical layer and the data link layer 
> of the interface do not implicitly change the state of each logical channel 
> at the packet layer. Such changes when they occur are explicitly indi- 

> cated at the packet layer by use of restart, clear or reset procedures as 

> appropriate. 


> 4.6.2 Definition of an out-of-order condition 


> In the case of a single link procedure, there is an out-of-order condition 
> when: : 

> e a failure on the physical and/or data link layer is detected: a 

> failure being defined as a condition in which the DCE cannot 

> transmit or cannot receive any frame because of abnormal condi- 
> tions caused by, for instance, a line fault between DTE and DCE; 
> Note: 

> short physical layer outages (e.g. loss of carrier) are not 
= considered as physical layer failures by the DCE and the 
> data link and packet layers are not informed. 

> -¢ the DCE has received or transmitted a DISC command. 

> _ There may be other network-dependent out-of-order conditions such as: 
> e reset of the data link layer, 

> e expiration of T3 timer (see § 2.4.5.3), 

> | e receipt or transmission of a DM response, 

> ° etc. 


> In the case of the Multilink procedure, an out-of-order condition is consid- 
> ered as having occurred when it is present at the same time for every 

> single link procedure of the DTE/DCE interface. There may be other 

> network-dependent out-of-order conditions such as the performance by 

> DTE or DCE of the multilink resetting procedure (see § 2.5.4.2), loss of 
multilink frame(s) (see § 2.5.4.4), etc. 
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> 4.6.3 Packet Layer Actions on Out-Of-Order Conditions 


> When an out-of-order condition is detected, the DCE will transmit to the 

> remote end: 

> 1. a reset with the cause “Out-of-Order” for each permanent virtual 
> circuit; and, 

> 2. a Clear with the cause “Out-of-Order” for each existing virtual call. 
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> 4.6.4 Packet Layer Actions during Out-Of-Order Conditions 


> During an out-of-order condition: 

> e the DCE will clear any incoming virtual call with the cause “Out-of- 
> Order”; 

> e for any data or interrupt packet received from the remote DTE on 
> a permanent virtual circuit, the DCE will reset the permanent 

ee virtual circuit with the cause “Out-of-Order’; 

> e areset packet received from the remote DTE on a permanent 

> virtual circuit will be confirmed to the remote DTE by either reset 
> confirmation or reset indication packet. 

> When an out-of-order condition is recovered: 

- e The DCE will send a restart indication packet with the cause 

= “Network operational” to the local DTE: 

a ¢ a reset with the cause “Remote DTE Operational” will be trans- 
2 mitted to the remote end of each permanent virtual circuit. 


IBM SNA X.25 DTEs report all “Out-of-Order” cause and diagnostic codes 
to a higher layer. 
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Chapter 5. Packet Formats 


5.1 General 


A packet always consists of at least three octets. These three octets 
contain the General Format Identifier Field, the Logical Channel Identifier 
Field, and the Packet Type Identifier Field. Depending on the ep aacuigy 
packet type, other fields may also be defined. 


The possible extension of X.25 packet formats by the addition of new fields 
is being considered by the CCITT. 


Nofe: 
Any such field: 


e would only be provided as an addition following all previously 
defined fields, and not as an insertion between any of the pre- 
viously defined fields; 


e would be transmitted to a DTE only when either the DCE has 
been informed that the DTE is able to interpret this field and 
act upon it, or when the DTE can ignore the field without 
adversely affecting the operation of the DTE/DCE interface 
(including charging); and, 


e would not contain any information pertaining to a user facility 
to which the DTE has not subscribed, unless the DTE can 
ignore the facility without adversely affecting the operation of 
the DTE/DCE interface (including charging). 


Note: 


This warning suggests that, in the interest of efficiency and 
upward compatibility with future versions of X.25, care should be 
taken not to reject received packets whose length would exceed 
what is usually expected for a given packet type; and, that inter- 
pretation of the packet should proceed so as to act on previously 
defined fields and ignore newly defined fields. However, such a 
position has not been embraced in the standards arena where, 
emerging conformance tests require that receipt of packets 
exceeding the maximum length be treated as format errors. Pru- 
dence, therefore, suggests that products in development include 
length checks where appropriate. 


Bits of an octet are numbered 8 to 1 where bit 1 ts the low order bit and is 


transmitted first. Octets of a packet are consecutively numbered starting 
from ‘1° and are transmitted in this order. 
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9.1.4 General Format Identifier 
The General Format Identifier (GFI) field is a four bit binary coded field 
which is provided to indicate the general format of the rest of the header. 
The General Format Identifier field is located in bit positions 8, 7, 6 and 5 
of octet 1, and bit 5 is the low order bit (see Table 16). See also 
“Relationship to ISO Open System Interconnection (OSI)” on page 9-5. 


Bit 8 of the General Format Identifier is the Qualifier ‘Q’ bit in DATA 
packets, the Address bit in call set-up and clearing packets, and is set to 
‘0’ in all other packets. 


Bit 7 of the General Format Identifier is used for the delivery confirmation 
procedure in DATA and Call Set-up packets and is set to ‘0’ in all other 
packets. It must be ‘0’ in all packets on SNA-to-SNA connections. 


Bits 6 and 5 are encoded for four possible indications. Two of the codes 
are used to distinguish packets using modulo ‘8’ packet sequence num- 
bering from packets using modulo ‘128’ packet sequence numbering. The 
third code is used to indicate an extension to an expanded format for a 
family of General Format Identifier codes which are being considered by 
the CCITT. The fourth code is reserved for other applications (see 

Figure 9-2 on page 9-7). 


Notes: 


1. The DTE must encode the GFI to be consistent with whether or not 
it has subscribed to the Extended Packet Numbering facility {see § 
6.2). 


2. It is envisaged that other general format identifier codes could 
identify alternative packet formats. 


3. Other GFI values (i.e., x‘0, 4, 7, 8, B, C and F’) are considered 
invalid and ignored by IBM SNA X.25 DTEs which take no action 
except to inform a higher layer of their receipt. 
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Table 16: General Format Identifier 


Octet 1 
bits 
8765 


0001 


Sequence Numbering Scheme Modulo 128 
Tien ome eierenesin et 


Reserved for other applications 2S OO 2 


General format identifier 


Call Set-Up Packets 


Clearing Packets 


Flow Control, Interrupt, 
Reset, Restart, 
Registration and 
Diagnostic packets 


Sequence Numbering Scheme Modulo 8 


DATA packets 


* Undefined 


Note: A bit which is indicated as "X" may be set to either '0' or '1' as 
indicated in the text. 


5.1.2 Logical Channel Group Number 
The Logical Channel Group Number appears in every packet except 
RESTART, DIAGNOSTIC and REGISTRATION packets in bit positions 4, 3, 2 
and 1 of octet 1. For each logical channel, this number has local signif- 
icance at the DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the Logical 
Channel Group Number. In RESTART, DIAGNOSTIC and REGISTRATION 


packets, this field is coded x‘0’. 


5.1.3 Logical Channel Number 
The Logical Channel Number appears in every packet except RESTART, 
DIAGNOSTIC and REGISTRATION packets tn all bit positions of octet 2. 
For each logical channel, this number has local significance at the 
DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the Logical 


Channel Number. In RESTART, DIAGNOSTIC and REGISTRATION packets, 
this field is coded x‘00’. : 
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5.1.4 Packet Type identifier 


Each packet is identified in octet 3 according to Table 17. 


Table 17: Packet Type Identifier 


OCTET 3 
BITS 
9 4 3 


PACKET TYPE 


From DCE to DIE From DTE to DCE 6 


Call Set-up and Clearing 


INCOMING CALL — (INC) CALL_REQUEST — (CRQ) 
CALL CONNECTED — (CCN) CALL_ACCEPTED — (CAC) 
| CLEAR INDICATION — (CLI) CLEAR REQUEST — (CLR) 


| DCE CLEAR CONFIRMATION — NCC) DTE CLEAR CONFIRMATION — (TCC) 


Data and [Interrupt] 


DCE DATA — (NDT) DTE_DATA - (TDT) 
[DCE INTERRUPT] — (NIN) [OTE INTERRUPT] — TIN) 
[DCE_INTERRUPT_ [OTE INTERRUPT 


CONFIRMATION] - (NIC) CONFIRMATION] ~ (TIC) 


Flow Control and Reset 


DCE RR (MODULO 8) — (NRR) DTE_RR (MODULO 8) — (TRR) XXX00001 
DCE RR (MODULO 128)* — (NRR) DTE RR (MODULO 128)* — (TRR) 80000001] 
DCE RNR (MODULO 8) — (NNR) DTE RNR (MODULO 8) — (TNR) XXX00101 
DCE RNR (MODULO 128)* — (NNR) DTE_RNR (MODULO 128)* — (TNR) 90000101 
DTE_REJ (MODULO 8)* — (TRJ) XXX01001 
DTE REJ (MODULO 128)* — (TRJ) 90001001 
| RESET INDICATION — (RSI) RESET REQUEST — (RSR) 90011611] 
DCE_RESET CONFIRMATION — (NRC) DTE_RESET CONFIRMATION — (TRC) 60011111 


Restart 
RESTART INDICATION — (IRT) RESTART REQUEST —- (IRR) 
| DCE RESTART CONFIRMATION — (NSC) DTE RESTART CONFIRMATION — (TSC) 


Diagnostic 


DIAGNOSTIC* — (DGN) 


Registration* 
| REGISTRATION REQUEST — (RRQ) 
REGISTRATION CONFIRMATION — (RCN) 


* = Not necessarily available on every network. 
Note: A bit which is indicated as "X" may be set to either 'O' or ‘1! 
as indicated in the text. 


Notes on Table 17:: 


1. Modulo 128 numbering is used only with the Extended Packet 
sequence as Numbering Facility. 


2. ADTE may transmit a REJECT packet only if the optional Packet 
Retransmission Facility has been subscribed to for transmission of 
REJECT packets. 
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3. A DCE will never transmit a REJECT packet and, therefore, a DTE 
need not be able to process a received REJECT packet in a 
DTE/DCE environment. On the other hand, a DTE must be able to 
process a received REJECT packet in a DTE/DTE environment only 
if the agreement to use the optional Packet Retransmission 
Facility includes retransmission of DATA packets by the DTE. 


4. A DTE may transmit a DIAGNOSTIC packet only in a DTE/DTE 
environment and only if it can be set to suppress its generation 
when connected to a network. 


5. In a DTE/DCE environment, a DTE may receive a DIAGNOSTIC 
packet from a DCE if implemented by the network. In a DTE/DTE 
environment, a DTE may receive a DIAGNOSTIC packet from a 
DTE only if the transmitting DTE can be set to suppress its gener- 
ation when connected to a network. 


6. Registration packets are used only if the optional On-line Facility 
Registration Facility has been subscribed to. 


7. A DCE will never transmit a REGISTRATION REQUEST packet and, 
therefore, a DTE need not be able to process a received REGIS- 
TRATION REQUEST packet in a DTE/DCE environment. On the 
other hand, a DTE must be able to process a received REGISTRA- 
TION REQUEST packet in a DTE/DTE environment only if the 
agreement to use the optional On-line Facility Registration Facility 
includes the DTE responding to registration-procedure initiation. 


8. A DTE may not transmit a REGISTRATION CONFIRMATION packet 
in a DTE/DCE environment. On the other hand, a DTE must be 
able to transmit a REGISTRATION CONFIRMATION packet in 
response to a REGISTRATION REQUEST packet only if the agree- 
ment to use the optional On-line Facility Registration Facility 
includes the DTE responding to registration-procedure initiation. 


5.2 Call Set-Up and Clearing Packets 


> 5.2.1 Address Block Format 


VVVVV VV 


VeVVWV VY 


VV 


The call set-up and clearing packets contain an address block. This 
address block has two possible formats: a non TOA/NPI (Type of 
Address/Numbering Plan Identifier) address format and a TOA/NPI 
address format. These two formats are distinguished by bit 8 of the 
general format identifier (A bit). When the A bit is set to 0, the non 
TOA/NPI address format is used. When the A bit is set to 1, the TOA/NPI 
address format is used. 


The non TOA/NPI address format is supported by all networks. The 
TOA/NPI address format may be supported by some networks, in partic- 
ular by those networks wishing to communicate with ISDNs for which the 
non TOA/NPI address format provides insufficient addressing capability. 


Note: 


Prior to 1997, packet-mode DTEs operating according to case B of 
CCITT Recommendation X.31 (ISDN virtual circuit bearer service) 
will be addressed by a maximum 12 digit address from the E.164 
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numbering plan. After 1996, such packet-mode DTEs may have 15 
digit E.164 address; TOA/NPI address procedures will be required 
to address the DTEs. CCITT Recommendations E.165 and E.166 
provide further guidance. 


When transmitting a call set-up or clearing packet, a DCE will use the TOA/NPI 
address format if the DTE has subscribed to the TOA/NPI address subscription 
facility (see § 6.26), the non TOA/NPI address format if it has not. 


Note: | 


This facility is designated in CCITT. Recommendation X.32 as “for 
further study.” : 


When transmitting a call setup or clearing packet, a DTE will use the TOA/NPI 
address format if it has subscribed to the TOA/NPI address subscription facility, 
the non TOA/NPI address format if it has not. 


When the address format usea by one DTE in a call set-up or clearing packet is 
different from the address format used by the remote DTE, the network (if it 
supports the TOA/NPI address format) converts from one address format to the 
other (see § 6.28). 


> 5.2.1.1 Format of the address block when the A bit is set to 0 


> 


VVWVWVVVVVV VV VV VV 


VVVV 


V 
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Figure 4 illustrates the format of the address block when the A bit is set to 0. 


8 / 6 5 4 3 2 1 


Calling DTE address length Called DTE address length 


Called DTE address 


| (see Note) 


Calling DTE address | 
(see Note) 


Note: The figure is drawn assuming the number of address digits 
present in the called DIE address is odd and the number 
of address digits present in the calling DTE address field 
is even. 


Figure 5-1. Format of the address block when the A bit ts set to 0 


Called and calling DTE address length fields: These fields are four bits long 
each and consist of field length indicators for the called and calling DTE 
addresses. Bits 4, 3, 2 and 1 indicate the length of the called DTE address in 
semi-octets. Bits 8, 7, 6 and 5 indicate the length of the calling DTE address in 
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semi-octets. Each DTE address length indicator is binary coded and bit 1 or bit 
9 is the low order bit of the indicator. 


Called and calling DTE address fields: Each digit of an address is coded ina 
semi-octet in binary coded decimal with bit 5 or bit 1 being the low-order bit of 
the digit. 


Starting from the high order digit, the address is coded in octet 5 and consec- 
utive octets with two digits per octet. In each octet, the higher order digit is 
coded in bits 8, 7, 6 and 5. 


When present, the calling DTE address field starts on the first semi- octet fol- 
lowing the end of the called DTE address field. Consequently, when the number 
of digits of the called DTE address field is odd, the beginning of the calling DTE 
address field, when present, is not octet aligned. 


When the total number of digits in the called and calling DTE address fields is 
odd, a semi-octet with zeros in bits 4, 3, 2 and 1 will be inserted after the calling 


DTE address field in order to maintain octet alignrnent. 


Further information on the coding of called and calling DTE address fields is 
given in Appendix V, “Addresses in Call Set-up and Clearing Packets.” 
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Note: 


These fields may be used for optional addressing facilities such as 
abbreviated addressing. The optional addressing facilities 
employed as well as coding of those facilities are being consid- 
ered by the CCITT. 


> 5.2.1.2 Format of the address block when the A bit is set to 1 


> 


ONE ONE AME ONE ONE ONE NEN NS NEON ME NEON 


V VVVYV 


VVV VV 


Figure 5 illustrates the format of the address block when the A bit is set to 1. 


Called DTE address length 


Calling DIE address length 


Called DIE address 
(see Note) 


Calling DTE address | 
(see Note) 


Note: The figure is drawn assuming the number of semi-octets 
present in the called DTE address is odd and the number 
of semi-octets present in the calling DIE address field 
iS even. 


Figure 5-2. Format of the address block when the A bit is set to 1 


Called and calling DTE address length fields: These fields are one octet long 
each and consist of field length indicators for the called and calling DTE 
addresses. They indicate the length of the called D1 E address and the calling 
DTE address, respectively in semi-octets. Each DTE address length indicator is 
binary coded and bit 1 is the low order bit of the indicator. 


The maximum value of a DTE address length indicator is 17. 


Called and calling DTE address fields: These fields respectively consist of the 
called DTE address when present, and the calling DTE address when present. 
Each DTE address when present, has these sub-fields: 


¢ type of address subfield (TOA), 
e numbering plan identification subfield (NPI), 
e address digits subfield. 


The first two subfields are at the beginning of the address and are binary coded 
with the values indicated in Figures 5-3 and 5-4. 
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Note: 


Currently, no non-BCD encodable values have been allocated for 
type of address and numbering plan identification subfields. 


A DTE address containing type of address and numbering plan 
identification subfields but no address digits subfield is invalid. 


Bits: & -7 6 BD 
or Type of address 
Bits: 4 3 2 1 

(see note 1) 


Network dependent number (see note 2) 


National number (see note 3) 
o be defined} Complementary address alone (note 4) 
other values | Reserved 


0 
0 International number (see note 3) 
0 
t 


Notes: 


1. The type of address subfield of the called DTE address field uses 


Figure 


bits 8, 7,6 and 5. The type of address subfield of the calling DTE 
address field uses bits 4, 3, 2 and 1 if the called DTE address field 
does not end on an octet boundary, otherwise, it uses bits 8, 7, 6 
and 9. 


. In this case, the address digits subfield present after the type 


of address and numbering plan identification subfields is organized 


according to the network numbering plan, e.g., prefix or escape code 
might be present. This case is equivalent to the use of the same code 


point in Q.931 where it is called “unknown”. 


. AS per Q.931, prefix or escape codes shall not be included in the 


address digits subfield. 


. For the definition of a complementary address, see 


Appendix V, “Addresses in Call Set-up and Clearing Packets.” 


5-3. Coding of the type of address subfield 
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V 


Bits: 8.7 6. o 
or Numbering plan 
Bits: 4 3 2 1 

(see note 1) 


0001 X.121 (see Note 2) 
to be defined| Network-dependent (see Note 3) 
other values | Reserved (see Note 4) 


Notes: 


1. The numbering plan identification subfield of the called DTE address 
field uses bits 4, 3, 2 and 1. The numbering plan identification 
subfield of the calling DTE address field uses bits 8, 7, 6 and 5 if the 
called DTE address does not end on an octet boundary, otherwise it uses 
bits 4, 3, 2 and 1. 


2. A mechanism equivalent to that provided by escape digits as defined 
in CCITT Recommendation X.121, is not yet defined for use in conjunction 
with the TOP/NPI capability. Such a mechanism will not use the numbering 
plan identification subfield. Until the availability of such a 
mechanism (potentially, an optional user facility), only the code point 
for X.121 shall be used. The X.121 escape codes shall apply and, when 
they are used, the type of address subfield shall indicate network 

dependent numbers. 


3. In this case, the address digits subfield present after the type of 
address and numbering plan identification subfields is organized 
according to the network numbering plan, e.g., prefix or escape code 
might be present. 


4. Included.among the reserved values are those corresponding to 
numbering plan identifiers in Q.931 (e.g., F.69, E.164).organized 


Figure 5-4. Coding of the numbering plan subfield 


The other semi-octets of a DTE address are digits, coded in binary coded 
decimal with bit 5 or 1 being the low order bit of the digit. Starting from the 
high order digit, the address digits are coded in consecutive semi-octets. In 
each octet, the higher order digit is coded in bits 8, 7, 6 and 5. 


When present, the calling DTE address field starts on the first semi- octet fol- 
lowing the end of the called DTE address field. Consequently, when the number 
of semi-octets of the called DTE address field is odd, the beginning of the 

calling DTE address field, when present, is not octet aligned. 


When the total number of semi-octets in the called and calling DTE address 
fields is odd, a semi-octet with zeros in bits 4, 3, 2 and 1 will be inserted after 
the calling DTE address field in order to maintain octet alignment. 


Further information on the coding of called and calling DTE address fields is 
given in Appendix V, “Addresses in Call Set-up and Clearing Packets.” 
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Note: 


These fields may be used for optional addressing facilities such as 
abbreviated addressing. The optional addressing facilities 
employed as well as the coding of these facilities are for further 
study. 


VVVV 


5.2.2 CALL REQUEST and INCOMING CALL Packets 
Figure 5-5 illustrates the format of CALL REQUEST and INCOMING CALL 
packets. 


In a DTE/DCE environment, the CALL REQUEST packet and INCOMING CALL 
packet are two different “physical” packets because of the intervening network. 
However, in a DTE/DTE environment, the CALL REQUEST packet sent by one 
DTE is the same as the INCOMING CALL packet received by the other DTE. 


Mm Nn NM MN 


General Format Identifier (GFI) 
(see Note) 


Address Block 
| (see § 5.2.1) 


VVVV 


Facility Length 


Facilities 


po oe 


| Call User Data (see Note 2) | 


eee eee ED ESRC AOE karte SCS ee ee Mere Mee eee os eT Re Seren eee RE Pie are 


Notes: 1. GFI — Coded XYQ1 (modulo 8) or XX10 (modulo 128). 
Where: 'Y = 0' on SNA-to-SNA Connections. 
'Y = 0 or 1' on SNA-to-non SNA Connections. 
2. The first octet of the Call User Data field is required and 
bits 8 and 7 have particular significance (see Protocol 
Identifier (PI)) 


+++ 


Figure 5-5. CALL_REQUEST and INCOMING_CALL Packet Format 
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5.2.2.1 General Format Identifier 
> | Bit 8 of octet 1 (A bit) should be set as described in § 5.2.1. On SNA-to-non 
SNA connections, bit 7 of octet 1 is set to ‘0’ unless the ‘D’ bit mechanism 
defined in § 4.3.3 is used. CALL REQUEST and INCOMING CALL packets must 
have bit 7 of octet 1 set to ‘0°’ on SNA-to-SNA connections. 


> §.2.2.2 Address block 
> , The address block is described in § 9.2.1. 


5.2.2.3 Facility Length Field | 7 
_ The octet following the Address field indicates the length of the Facility field in 
octets. The facility length indicator is binary coded and bit 1 is the low order bit 
of the indicator. 


5.2.2.4 Facility Field 
; The Facility field is present only when the DTE is using an optional user facility 
requiring some indication in CALL REQUEST and INCOMING CALL packets. 


The coding of the Facility field is defined in §§ 6.0 and 7.0. . 
The Facility field contains an integral number of octets. The actual maximum 


length of this field depends on the facilities that are offered by the network. 
However, this maximum does not exceed 109 octets. 


> Note: 
> It is for further study whether another value should be defined, rel- 
> ative to the total number of octets in a packet. 


9.2.2.0 Call User Data Field 
Following the facility field, the. Call. User Data field may be present and has a 
maximum length of 128 octets when used in conjunction with the Fast Select 
facility described in § 6.16, 16 octets in the other case. | 


Protocol Identifier (Pl) 


5 This section applies to IBM SNA DTEs only. See § 9.4.1. 


The first octet of the Call User Data field is the Protocol Identifier (Pl) which is 
mandatory in SNA environments. 


The use and format of the Call User Data field is determined by the setting of 
bits 8 and 7 of the first octet of this (Protocol Identifier) field. If bits 8 and 7 of 
the first octet of the Call User Data field are: 


‘41’ the Call User Data belongs to a higher layer. 


Receipt of an incorrect setting of bits 8 or 7 (other than 11’), by 
IBM SNA X.25 DTEs results in call clearing with the diagnostic 
code x‘EB’, “Invalid Protocol Identifier.” 


Bit 2 of the Protocol Identifier also has particular significance in 
SNA environments: 


‘0’ - for SNA-to-non SNA connections; or, 


‘4’ - for SNA-to-SNA connections. 
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+++ + 


Note: 


Some networks require the Call User Data field to contain an integral 
number of octets (see § 3, Note 1). 


When a virtual call is being established between two packet mode DTEs, the 
network does not act on any part of the Call User Data field. In other circum- 
stances, see CCITT Recommendation X.244. 


5.2.3 CALL_ACCEPTED and CALL_CONNECTED Packets 


Figure 5-6 illustrates the format of CALL ACCEPTED and CALL_ CONNECTED 
packets in the basic and extended format. 


In a DTE/DCE environment, the CALL_ACCEPTED packet and 

CALL_ CONNECTED packet are two different “physical” packets because of the 
intervening network. However, in a DTE/DTE environment, the | 
CALL_ACCEPTED packet sent by one DTE is the same as the 
CALL_CONNECTED packet received by the other DTE. 


Bits 
8 7 6 5 4 3 2 1 
Octet 


General format identifier (GFI)] Logical channel group number 
i (see Note) 
2 Logical channel number 


3 Packet type identifier 


Address block 
| (see Chapter 5.2.1) | 


a ) 
Facility length 


Facilities 


| Call_User Data | }b) 


Pa a ee 


a) These fields are not mandatory in CALL ACCEPTED packets (see § 
b) This field may be present only in the extended format (see § 5. 


Note: 


GFI — Coded XYQ1 (modulo 8) or 0X10 (modulo 128). 
Where Y = 'O' on SNA-to-SNA connections; and, 
Y = 'O' or '1' on SNA-to-non SNA connections. 


Figure 5-6. CALL_ACCEPTED and CALL_CONNECTED Packet Format 
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5.2.3.1 Basic Format 


e General Format identifier 
> Bit 8 of octet 1 {A bit) should be set as described in § 5.2.1. 


On SNA-to-non_SNA connections, bit 7 of octet 1 is equal to ‘0’ 
unless the ‘D’ bit mechanism defined in § 4.3.3 is used. 


CALL. ACCEPTED and CALL_ CONNECTED packets must have bit 7 
of octet 1 set to ‘0’ on SNA-to-SNA connections. 


> e Address block 

> The address block is described in § 5.2.1. 

S Address Length Fields are required in CALL_ACCEPTED packets, 
S even if they are set to zero. 


¢ Facility Length Field 


The octet following the Address Block indicates the length of the 
facility field in octets. The facility length indicator is binary coded 
and bit 1 is the low order bit of the indicator. 


S | The Facility Length Field is required in CALL_ ACCEPTED packets, 
S even if it is set to zero. 
e Facility Field 


The facility field is present only when the DTE is using an optional 
user facility requiring some indication in the CALL_ACCEPTED and 
CALL CONNECTED packets. 


The coding of the facility field is defined in §§ 6.0 and 7.0. 


The facility field contains an integral number of octets. The actual 
maximum length of this field depends on the facilities which are 
offered by the network. However, this maximum does not exceed 


109 octets. 
> | Note: 
> It is for further study whether another value should be 
> | defined, relative to the total number of octets in the packet. 


5.2.3.2 Extended Format 
The extended format may be used only in conjunction with the Fast_Select 
facility described in § 6.16. In this case, the Called User Data field may be 
present and has a maximum length of 128 octets. 


S To be in compliance with ISO 8208, the address length and facility length fields 
S must be present, even if they are set to zero. 
Note: 
some networks require the Called User Data field to contain an 
S integral number of octets (see § 3, Note 1). To be in compliance 
S with ISO 8208, this field must contain an integral number of octets. 


When the virtual call is being established between two packet-mode DTEs, the 
network does not act on any part of the Called User Data field. See CCITT 
Recommendation X.244. 
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5.2.4 CLEAR_REQUEST and CLEAR_INDICATION Packets 
Figure 5-7 illustrates the format of CLEAR_REQUEST and CLEAR_INDICATION 


packets 
S In a DTE/DCE environment, the CLEAR REQUEST packet and 
S CLEAR_INDICATION packet are two different “physical” packets because of the 
S intervening network. However, in a DTE/DTE environment, the 
S CLEAR REQUEST packet sent by one DTE is the same as the 
S CLEAR_INDICATION received by the other DTE. in basic and extended formats. 
Bits 
8 7 6 5 4 3 Z 1 
Octet 
1 General format identifier (GFI)} Logical channel group number 
2 Logical channel number 
3 Packet type identifier 
Q Q 0 0 0 1 1 
5 Diagnostic code 
(This field is mandatory on SNA-to-SNA Connections 
(see Note} 
> 
> 
> | Address Block 
> | (see Chapter 5.2.1) | 
> | 
> 
b). 
Facilities 
ull Clear User Data | 
n 
ee et ara eee Ee a 
b) These fields may be present only in the extended format 
(see § 5.2.4.2). 
> GFI — Coded X001 (modulo 8) or X010 (modulo 128). 


Note: Appendix H, "DTE-Generated Diagnostic Codes" 


Figure 5-7. CLEAR_REQUEST and CLEAR_INDICATION Packet Format 
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5.2.4.1 Basic Format 
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¢ Clearing Cause Field 


Octet 4 is the clearing cause field and contains the reason for the 
clearing of the call. 


In CLEAR REQUEST packets, the clearing cause field should be 
set by the DTE to one of the following values which indicate “DTE 
Originated”: 


bits: “Oo 27 ‘60° @ 3°22 7 
value: 09 0 0 0 8@ 0 98 8 
or: 1 x xX X X X xX xX where each 'x' may be 


independently set to 'Q' 
or '1' by the DTE. 


To be in compliance with !SO 8208, each ‘x’ must be set to ‘0’ by | 
the DTE. Other values for X are for use by Private Packet 
Switched Data Networks (which appear as DTEs to the public 
network). 


The DCE will prevent values of the clearing cause field other than 
those shown above from reaching the other end of the call by 
either accepting the CLEAR REQUEST packet and forcing the 
clearing cause field to all zeros in the corresponding 
CLEAR_INDICATION packet, or considering the CLEAR_REQUEST 
as an error and following the procedure described in Appendix C, 
“Packet Layer DCE Actions.” 


In a DTE/DCE environment, a DTE must be able to accept any 
value in the Clearing Cause Field in a CLEAR_INDICATION packet. 
In a DTE/DTE environment, a DTE may either handle a clearing 
cause other than “DTE Originated” as it does in DTE/DCE envi- 
ronment (i.e., process the packet normally) or treat it as an error. 
In the latter case, the Packet Layer transmits a CLEAR_REQUEST 
packet with a cause indicating “DTE Originated” and the diag- 
nostic “Improper Cause Code From DTE.” 


The coding of the clearing cause field in CLEAR_INDICATION 
packets is given in Table 18. 


Ann nAAnA HAA 
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Table 18: Coding of the Clearing Cause Field in 
CLEAR INDICATION packets 


Bits | 8/65 4321 


DTE Originated 
DTE Originated- 


Number busy 

Out of order 

Remote procedure error 

Reverse charging acceptance not subscribed 
Incompatible destination 

Fast select acceptance not subscribed 

Ship absent. 


Invalid facility request 
Access barred 
Local procedure error 


Network congestion 
Not obtainable 
RPOA out of order 


Gateway-detected Procedure Error bob Oe). 2050.0 1: 
Gateway Congestion ta 3017] 


@) 


— May be received only if the corresponding optional user 
user facility is used. 
—- Used in conjunction with mobile maritime service. 


The bit indicated as "X" set to 0 indicates a resetting cause 
generated by a public data network and set to 1 indicates 
a resetting cause generated by a private network. 


« Diagnostic Code 


Octet 5 is the Diagnostic Code and provides additional information 
on the reason for the clearing of the call. 


In a CLEAR REQUEST packet, the Diagnostic Code Field is 
required, even if it indicates no additional information. 


Diagnostic Codes generated by IBM SNA X.25 DTEs for 
CLEAR_REQUEST packets on SNA-to-SNA and SNA-to-non-SNA 
connections are specified in Appendix H, “DTE-Generated Diag- 
nostic Codes.” 


In a CLEAR_INDICATION packet, if the Clearing Cause field indi- 
cates “DTE_ Originated,” the Diagnostic_Code is passed 
unchanged from the clearing DTE. If the clearing DTE has not pro- 
vided a Diagnostic Code in its CLEAR REQUEST packet, then the 
bits of the Diagnostic_Code in the resulting CLEAR_INDICATION 
packet will be x‘00’. 
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When a CLEAR_INDICATION packet results from a 

RESTART REQUEST packet, the value of the Diagnostic_Code will 
be that specified in the RESTART REQUEST packet, or x‘00’ in the 
case where no Diagnostic_Code has been specified in the 
RESTART REQUEST packet. 


When the Clearing Cause field does not indicate 
“DTE_Originated,” the Diagnostic _Code in a CLEAR_INDICATION 
packet is network generated. Appendix E, “Network Generated 
Diagnostic Codes” lists the codings for network generated diag- 
nostics. The bits of the Diagnostic_Code are all set to ‘0’ when no 
specific additional information for the clearing is supplied. 


Note: 


‘The contents of the Diagnostic_Code field do not alter - 
the meaning of the Cause field... A DTE is not 

required to undertake any action on the contents of 
the Diagnostic Code field. IBM SNA X.25 DTEs must 
report the contents of the Diagnostic Code and 
Clearing Cause fields to a higher layer of SNA. 
Unspecified code combinations in the 

Diagnostic_Code field shall not cause the DTE to 
refuse the cause field. 


9.2.4.2 Extended Format 
The extended format is used for CLEAR_REQUEST and CLEAR_INDICATION | 
packets only when the DTE or the DCE needs to use the address field, the 
facility field and/or the Clear User Data field in conjunction with one or several. 
optional user facilities described in §§ 6.0 and 7.0. The address field is used 
only when the Called Line Address Modified Notification facility is used in 
clearing, in response to an INCOMING CALL or CALL REQUEST packet. The 
Facility Field is used when the Charging Information Facility is present. The 
Clear User Data Field is used in conjunction with the Fast_Select Facility. 


When the extended format is used, the Diagnostic_Code field, the 
Address _ Length fields and the Facility_ Length field must be present. 
Optionally, the Clear User Data field may also be present. 


« Address Block 
The address block is described in § 5.2.1. 
e Facility Length Field 


The octet following the address block indicates the length of the 
facility field in octets. The facility length indicator is binary coded 
and bit 1 is the low order bit. 


° Facility Field 


The facility field is present in the CLEAR REQUEST or the 
CLEAR_INDICATION packet only in conjunction with one or several 
optional user facilities requiring some indication in this packet. 


The coding of the facility field is defined in §§ 6 and 7. 
Note: 


It is for further study whether another value should be 
defined, relative to the total number of octets in the packet. 


5-18 Architecture Reference 


VVVV V 


VVVV 


The facility field contains an integral number of octets. The actual 
maximum length of this field depends on the facilities which are 
offered by the network. However, this maximum does not exceed 
109 octets. 


e Clear User Data Field 


This field may be present only in conjunction with the Fast Select 
facility (see § 6.16) or the Call Deflection Selection facility (see § 
6.25.2.2). It has a maximum length of 128 octets in the first case, 
of 16 or 128 octets in the second case: whether the maximum 
length is 16 or 128 octets when using the Call Deflection Selection 
facility is specified in § 6.25.2.2. 


Notes: 


1. Some networks require the Clear User Data field to 
contain an integral number of octets (see note in § 3). 


2. The network does not act on any part of the clear 
user data field. See CCITT Recommendation X.244. 


9.2.5 DTE and DCE CLEAR_CONFIRMATION Packets 
Figure 5-8 illustrates the format of DTE and DCE CLEAR CONFIRMATION 
packets, in the basic or extended format. 


Address Block | 
| (see § 5.2.1) | 


| r 
Facility Length 
: Facilities 
i 
a) These fields may be present only in the extended format of 


DCE CLEAR CONFIRMATION packets. 
GFI — coded X001 (mod 8) or X010 (mod 128) 


Figure 5-8. DTE and DCE_CLEAR_CONFIRMATION Packet Format 
The extended format may be used for DCE_ CLEAR_CONFIRMATION packets 


only in conjunction with the Charging Information facility described in § 6.22. It 
is not used for DTE_CLEAR_ CONFIRMATION packets. 
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e Address Block 
The address block is described in § 5.2.1. 


The calling and called DTE address length fields are coded with all 
zeros and the called and calling DTE address fields are not 
present. 


e Facility Length Field 


The octet following the address block indicates the length of the 
facility field in octets. The facility length indicator is binary coded 
and bit 1 is the low order bit of the indicator. 


e Facility Field 
The-coding of the facility field is defined in §§ 6 and 7. 


The facility field contains an integral number of octets. The actual 
maximum length of this field depends on the facilities which are 
offered by the network. However, this maximum does not exceed 
109 octets. -_ 


Note: 


lt is for further study whether another value should be 
defined, relative to the total number of octets in the packet. 


5.3 Data [and interrupt, Packets 


The packets described in this section are used for transmitting data or are used 
with the interrupt procedure. They include the following packets: — 


© DATA 
° INTERRUPT 
¢ INTERRUPT_CONFIRMATION. 


5.3.1 DTE and DCE DATA Packets 
Figure 5-9 on page 5-21 illustrates the format of DTE and DCE_DATA packets. 
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General format identifier (GFI) 
Q D 0 i 


User Data 


General format identifier (GFI)| 


Q D 1 0 


User data 


(Modulo 128) 
D = Delivery confirmation bit (= '@' on SNA-to-SNA Connections). 


M = More Data bit 
Q = Qualifier bit 


| 


Figure 5-9. DTE and DCE DATA Packet Format 


9.3.1.1 Qualifier (Q) Bit 
Bit 8 of octet 1 is the Qualifier (‘Q’) bit. It is used on SNA-to-SNA connections to 


identify ‘Qualified’ DATA packets as described in § 8.0. 


9.3.1.2 Delivery Confirmation (D) Bit 
Bit 7 of octet 1 is the Delivery Confirmation bit. 


9.3.1.3 Packet Receive Sequence Number, Pr 
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the 


Packet Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 
when extended, is the low order bit. 
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5.3.1.4 More Data (M) Bit 
Bit 5 in octet 3, or bit 1 in octet 4 when extended, is the More Data mark (‘M’ 
bit): 
‘M =0’ for no more data; and, 
‘M=1' for more data. 


5.3.1.5 Packet Send Sequence Number, Ps 
Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended, are the 
Packet Send Sequence Number (Ps). Ps is binary coded and bit 2 is the low 
order bit. 


5.3.1.6 User Data Field 


Bits following octet 3, or octet 4 when extended, contain user data. 
Note: 


The User Data field field must contain an integral number of 
octets. 


5.3.2 DTE and DCE INTERRUPT Packets 


5.3.2.1 SNA-to-SNA Connections | 
INTERRUPT packets are not allowed on SNA-to-SNA connections. IBM SNA 
X.25 DTEs clear the virtual call or reset the permanent virtual circuit with the 
diagnostic #170 “Not Supported” upon receipt of a DCE_INTERRUPT or 
DCE_INTERRUPT CONFIRMATION packet. 


9.3.2.2 SNA-to-non_SNA Connections 
Figure 5-10 illustrates the format of DTE and DCE INTERRUPT packets. 


General format identifier (GFI 


Packet type identifier | 
Q Q 0 


| Interrupt user data | 
GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 


Figure 5-10. DTE and DCE INTERRUPT Packet Format 


e Interrupt User Data Field 


Octet 4 and any following octets contain the Interrupt User Data. This 
field may contain from 1 to 32 octets. 
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Note: 


S The Interrupt User Data field must contain an integral number of 
S octets. 


5.3.3 DTE and DCE_INTERRUPT_CONFIRMATION Packets 


9.3.3.1 SNA-to-SNA Connections 
INTERRUPT CONFIRMATION packets are not allowed on SNA-to-SNA con- 
nections. 


5.3.3.2 SNA-to-non SNA Connections | 
Figure 5-11 illustrates the format of DTE and DCE_INTERRUPT CONFIRMATION 
packets. 


General format identifier (GFI 


Packet type identifier 
1 0 0 ui 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 
Figure 5-11. DTE and DCE_INTERRUPT_CONFIRMATION Packet Format 


5.4 Flow Control and Reset Packets 


S The packets described in this section are used to control the flow of DATA 
S packets (the DATA and REJECT packets are also used to control the flow of 
S DATA packets) and to (re)initialize the flow of both DATA and INTERRUPT 

S packets. They include: 

S | e RECEIVE READY 

S e RECEIVE NOT READY 

S e RESET REQUEST 

S e RESET CONFIRMATION. 


5.4.1 DTE and DCE_RECEIVE_READY (RR) Packets 
Figure 5-12 on page 5-24 illustrates the format of DTE and DCE_RR packets. 
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General format identifier (GFI) 
0 0 0 u 


Packet type identifier 


0 0 0 
(Modulo 8) 
Bits 
8 / 6 5 4 3 2 1 
Octet 

1 General format identifier (GFI)| Logical channel group number 

0 0 od) 0 
2 
3 Packet type identifier 

0 Q “0 0 

4 


(Modulo 128) 
Figure 5-12. DTE-and DCE_RR Packet Format 


9.4.1.1 Packet Receive Sequence Number, Pr 
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the 
Packet Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 
when extended, is the low order bit. 


5.4.2 DTE and DCE_RECEIVE_NOT_READY (RNR) Packet 
Figure 5-13 on page 5-25 illustrates the format of the DTE and DCE RNR 
packet. 
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General format identifier (GFI) 
0 0 0 1 


Logical channel number 


Packet type identifier 


C) 1 0 
(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 
Uctel 

1 General format identifier (GFI) 

0 0 1 0 
2 logical channel number 
3 Packet type identifier 


(Modulo 128) 
Figure 5-13. DTE and DCE_RNR Packet Format 


5.4.2.1 Seg Receive Sequence Number, Pr 
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are the 
Packet Receive Sequence Number (Pr). Pr is binary coded and bit 6, or bit 2 
when extended, is the low order bit. 


5.4.3 RESET_REQUEST and RESET_INDICATION Packets 
Figure 5-14 on page 5-26 illustrates the format of RESET REQUEST and 
RESET INDICATION packets. 


In a DTE/DCE environment, the RESET REQUEST packet and 

RESET INDICATION packet are two different “physical” packets because of the 
intervening network. However, in a DTE/DTE environment, the 

RESET REQUEST packet sent by one DTE is the same as the 

RESET INDICATION packet received by the other DTE. 


NAAR NH 
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General format identifier (GF1) 


Packet type identifier 


0 1 1 0 


| _ Diagnostic code 
(This field is mandatory on SNA-to-SNA Connections 
(see Appendix H)) 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 
Figure 5-14. RESET _REQUEST and RESET_INDICATION Facket Format 


5.4.3.1 Resetting Cause Field 
Octet 4 is the Resetting Cause field and contains the reason for the reset. 


In RESET REQUEST packets, the Resetting Cause field must be set by the DTE 
to one of the following values: 


bits: ~8 .7 6. BS 4 3° 2.4 
Valuer 6. @ 0-0 @ 0 O° 0 
1 x xX X X XxX xX xX where each x may be independently 


set to 'O' or '1' by the DTE. 


To be in compliance with ISO 8208, each ‘x’ must be set to ‘0’ by the DTE. 
Other values for X are for use by Private Packet Switched Data Networks (which 
appear as DTEs to the public network). 


The DCE will prevent values of the resetting cause field other than those shown 
above from reaching the other end of the virtual call or permanent virtual circuit 
‘by either accepting the RESET REQUEST packet and forcing the 

Resetting Cause field to all zeros in the corresponding RESET INDICATION 
packet, or considering the RESET REQUEST as an error and following the pro- 
cedure described in Appendix C, “Packet Layer DCE Actions.” 


The coding of the Resetting Cause field in a RESET INDICATION packet is 
given in Table 19. In a DTE/DCE environment, a DTE, in order to allow for pos- 
sible later extensions to Table 19, must be able to accept any value in the 
Resetting Cause Field in a RESET INDICATION packet. In a DTE/DTE environ- 
ment, a DTE may either handle a resetting cause other than “DTE Originated” 
as it does in a DTE/DCE environment (i. e., process the packet normally) or 
treat it as an error. In the latter case, the Packet Layer transmits a 

RESET REQUEST packet with a cause indicating “DTE Originated” and the diag- 
nostic “Improper Cause Code From DTE.” 
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Table 19: Coding of the Resetting Cause field in 
RESET INDICATION Packets 
Bits |} 8765 4321 


DTE Originated 0000 000 0 
DTE Originated 1000 0000 


Out of order 

Remote procedure error 
Local procedure error 
Network congestion 
Remote DIE operational 
Network operational 


Incompatible destination 
Network out of order 


>< >< >< OK OK OK OK OC 
Oooo0od 8} © @®& 
DOOD OOO O&O 
mere OOO DGD @ & 
mS OF FF © GO © © 
mH Ore Ore rH © © 
COOrOr OF @® 
a ee no ey 


Gateway-detected Procedure Error 
Gateway Congestion 
Gateway Operational 


£-Applicable to permanent virtual circuits only. 

The bit indicated as "X" set to 0 indicates a resetting cause 
generated by a public data network and set to 1 indicates 

a resetting cause generated by a private network. 


5.4.3.2 Diagnostic Code 


Octet 5 is the Diagnostic_Code field (mandatory on SNA-to-SNA connections) 
and contains additional information on the reason for the reset. 


Cause and Diagnostic Codes generated by IBM SNA X.25 DTEs for 
RESET REQUEST packets are shown in Appendix H, “DTE-Generated Diag- 
nostic Codes.” 


In a RESET REQUEST packet, the Diagnostic Code Field is required, even if it 
indicates no additional information. 


In a RESET_INDICATION packet, if the Resetting Cause field indicates “DTE 
Originated,” the Diagnostic Code has been passed unchanged from the remote 
DTE. In a RESET_ INDICATION packet, if the Resetting Cause field does not 
indicate “DTE Originated”, then the Diagnostic Code Field is network generated. 
If the DTE requesting a reset has not provided a Diagnostic_Code in its 

RESET REQUEST packet, then the bits of the Diagnostic Code in the resulting 
RESET INDICATION packet will be x00’. 


Ifa RESET INDICATION packet results from a RESTART REQUEST packet, the 
value of the Diagnostic_Code will be that specified in the RESTART REQUEST, 
or x‘00’ in the case where no Diagnostic _Code has been specified in the 
RESTART REQUEST packet. 


When the Resetting Cause field does not indicate “DTE Originated,” the 
Diagnostic Code in RESET INDICATION packets is network generated. 
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Appendix E, “Network Generated Diagnostic Codes” lists the codings for 
network generated diagnostics. The bits of the Diagnostic Code field are all set 
to ‘0’ when no specific additional information for the reset is supplied. 


Note: 


The contents of the Diagnostic Code field do not alter the meaning of 
the Cause field. A DTE is not required to undertake any action on the 
contents of the Diagnostic Code field. IBM SNA X.25 DTEs must report 
the contents of the Diagnostic Code and Resetting Cause fields to a 
higher level of SNA. An unspecified diagnostic code shall not cause the 
DTE to reject the cause field. 


5.4.4 DTE and DCE RESET CONFIRMATION Packets 


Figure 5-15 illustrates the format of DTE and DCE RESET CONFIRMATION 
packets. . 


Packet type identifier 
1 1 


0) 1 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 
Figure 5-15. DTE and DCE_RESET_ CONFIRMATION Packet Format 


5.5 Restart Packets 


5.5.1 RESTART_REQUEST AND RESTART_INDICATION PACKETS 


Figure 5-16 on page 5-29 illustrates the format of RESTART REQUEST and 
RESTART_INDICATION packets. 
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Bits 


8 4 6 5 4A 3 2 1 
Octet ae 
1 General format identifier (GFI)} Logical channel group number 
| 0 0 0 0 
2 
3 Packet type identifier 
1 1 

4 Restarting cause 
5 Diagnostic code 


(This field is mandatory on SNA-to-SNA Connections 
(see Appendix H)) 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 
Figure 5-16. RESTART REQUEST and RESTART_INDICATION Packet Format 


In a DTE/DCE environment, the RESTART REQUEST packet and 

RESTART INDICATION packet apply only at a local DTE/DCE interface. 

However, in a OTE/DTE environment, ihe RESTART REQUEST packet seni by 
one DTE is the same as the RESTART_INDICATION packet received by the other 
DTE. 


Ann AA 


9.5.1.1 Restarting Cause Field 


Octet 4 is the Restarting Cause field and contains the reason for the restart. 


In RESTART REQUEST packets, the Restarting Cause field should be set by the 
DTE to one of the following values: 

bits: 8 

value: Q 

1 


2 1 
0 0 
or: X X 


x © ns) 
~~ © MD 
x CO 
x © 
Kx DW 


where each 'x' may be 
independently set to 
'O' or '1' by the DTE 


VVVVV VV 


To be in compliance with ISO 8208, each ‘x’ must be set to ‘0’ by the DTE. 


” 


The DCE will prevent values of the restarting cause field other than those 
shown above from reaching the other end of the virtual call or permanent 
virtual circuit by either accepting the RESTART REQUEST packet and forcing 
the Restarting Cause field to all zeros in the corresponding | 
RESTART_INDICATION packet, or considering the RESTART REQUEST as an 
error and following the procedure described in Appendix C. 


VVVVVYV 


In a DTE/DCE environment, a DTE, in order to allow for possible later exten- 
sions to Table 20, must be able to accept any value in the Restarting Cause 
Field in a RESTART_INDICATION packet. In a DTE/DTE environment, a DTE may 
either handle a restarting cause other than “DTE Originated” as it does in a 
DTE/DCE environment (i.e., process the packet normally) or treat it as an error. 
In the latter case, the Packet Layer transmits a RESTART REQUEST packet with 


Mm A NM MMmM MN 
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S a cause indicating “DTE Originated” and the diagnostic “Improper Cause Code 
S from DTE.” : 


The coding of the Restarting Cause field in RESTART_INDICATION packets is 
given in Table 20. 7 


Table 20: Coding of the Restarting Cause field in 
RESTART INDICATION packets 


| Bits |8765 4321 

S DTE Originated* 0000 000090 
S DTE Originated* £60.08) 0:00 0 
Local Procedure Error 0000 0001 


Network congestion 
Network operational ; 
> Registration/Cancellation Confirmed-£Y 


£-May be received only if the optional 
On-Line Facility Registration facility is used. 
S *-These restarting causes apply only to a DTE/DTE environment. 
S All others apply only to a DTE/DCE environment. 


9.9.1.2 Diagnostic Code | | 
Octet 5 contains the Diagnostic_Code which provides additional information on 
the reason for the restart. : 


S In a RESTART REQUEST packet, the Diagnostic Code Field is required, even if 

S it indicates no additional information. Diagnostic Codes generated by IBM SNA 
X.25 DTEs for RESTART REQUEST packets are given in Appendix H, 

S “DTE-Generated Diagnostic Codes.” The Diagnostic Code is passed to the cor- 

S responding DTEs as Diagnostic _Code of a RESET_INDICATION packet on per- 


manent virtual circuits or a CLEAR_INDICATION paciet on virtual calls. 


The coding of the Diagnostic Code field in a RESTART_INDICATION packet is 
given in Appendix E. The contents of the Diagnostic Code field is set to x‘00’ 
when no specific additional information for the restart is supplied. 


Note: 


The contents of the Diagnostic Code field do not alter the meaning of 
the Cause field. A DTE is not required to undertake any action on the 
contents of the Diagnostic Code field. IBM SNA X.25 DTEs must report 
the contents of the Diagnostic Code field to a higher layer of SNA. 
Unspecified code combinations in the Diagnostic_Code field shall not 
cause the DTE to not accept the cause field. 
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5.9.2 DTE and DCE _RESTART_CONFIRMATION Packets 
Figure 5-17 illustrates the format of DTE and DCE RESTART CONFIRMATION 


packets. 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). 
Figure 5-17. DTE and DCE_RESTART_CONFIRMATION Packet Format 


5.6 Diagnostic Packet 


Figure 5-18 on page 5-32 lilustrates the format of the DIAGNOSTIC packet. 


All DTEs should be capable of receiving a DIAGNOSTIC packet. The DIAG- 
NOSTIC packet may be used in a DTE/DCE environment, and then only to be 
sent by aDCEto a DIE. The DIAGNOSTIC packet may be originated by a DTE 
only in a DTE/DTE environment provided its generation can be suppressed 
when connected to a network. 
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Packet type identifier 
1 Q 


Diagnostic code 


| Diagnostic explanation (see Note) 


Me es ee Fa et ce ere 


GFI — Coded 0001 (modulo 8) or 0010 (modulo 128). | 


Note: The diagnostic explanation field is required to be an 
integral number of octets in length. 


Figure 5-18. DIAGNOSTIC Packet Format 


5.6.1 Diagnostic Code Field 
Octet 4 is the diagnostic code and provides information on the error condition 
which resulted in the transmission of the DIAGNOSTIC packet. Diagnostic 
Codes are given in Appendix E, “Network Generated Diagnostic Codes.” 


5.6.2 Diagnostic Explanation Field 
When the DIAGNOSTIC packet is issued as a result of the reception of an erro- 
neous packet from the DTE (see Tables C-1 and C-2 in Appendix C, “Packet 
Layer DCE Actions”), this field contains the first three octets of header informa- 
tion from the erroneous DTE packet. If the packet contains less than 3 octets, 
this field contains whatever bits were received padded to an integral number of 
octets with ‘0’ bits. 


When the DIAGNOSTIC packet is issued as a result of a DCE time-out {see 
Table D-1 in Appendix D, “DCE Time-outs and DTE Time-limits”), the Diagnostic 
Explanation field contains 2 octets coded as follows: 


1. Bits 8, 7, 6 and 5 of the first octet contain the General Format Identifier 
for the DTE/DCE interface. 


2. Bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are x'000’ 
for expiration of time-out T10; and, give the identifier of the logical 
channel on which the time-out occurred for expiration of time-out T12 or 
713. 
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5.7 Packets required for optional user facilities 


5.7.1 DTE_REJECT (REJ) Packet for the Packet Retransmission Facility 


The DTE_REJ packet, used in conjunction with the Packet Retransmission 
facility described in § 6.4 is not used in SNA X.25 DTEs. 


5./.2 Registration Packets for the On-Line Facility Registration Facility 


9.7.2.1 REGISTRATION REQUEST Packet 


Figure 5-19 illustrates the format of the REGISTRATION REQUEST packet. 


Bits 


Packet Type Identifier 
1 0 


DTE Address Lenath DCE Address Lenath 


5 DCE and DTE Address(es) (see Note) 


V 


| Registration | 


GFI — Coded '0001' (modulo 8) or '0010' (modulo 128) 


Note: The figure is drawn assuming the total number of address 
digits present is odd. | 


Figure 5-19. REGISTRATION REQUEST Packet Format 


e Address Length Fields 


Octet 4 consists of the field length indicators for the DTE and DCE 
S addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE (or 
S remote DTE if DTE/DTE) address in semi-octets. Bits 8, 7, 6 and 5 
indicate the length of the DTE address in semi-octets. Each 
address length indicator is binary coded and bit 1 or 5 is the low 
order bit of the indicator. 


These fields are coded with all zeros under the procedures of this 
specification. 


« Address Field 
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Octet 5 and the following octets consist of the DCE address, when 
present, and the DTE address, when present. 


Each digit of an address is coded in a semi-octet in binary coded 
decimal with bit 5 or bit 1 being the low order bit of the digit. 


Starting from the high order digit, the address is coded in octet 5 
and consecutive octets with two digits per octet. In each octet, the 
higher order digit is coded in its 8, 7, 6 and 5. 


The address field shall be rounded up to an integral number of 
octets by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the 
field when necessary. . 


This field is not present under the procedures in this specification. 


e Registration Length Field 


The octet following the address field indicates the length of the 
registration field in octets. The registration length indicator is 
binary coded and bit 1 is the low order bit of the indicator. © 


e Registration Field 


The registration field is present only when the DTE wishes to 
request the DCE to agree to, or to stop a previous agreement for, 
an optional user facility. 


~The coding of the registration field is defined in § 7.3. 


The registration field contains an integral number of octets. The 
actual maximum length of this field depends on the network. 
However, this maximum does not exceed 109 octets. 


5.7.2.2 Registration Confirmation Packet 
Figure 5-20 illustrates the format of the REGISTRATION CONFIRMATION 


packet. 


3 Packet Type Identifier 
1 i 1 1 
: 
: 
6 DTE Address Length DCE Address Length 
DCE and DTE Address(es) (see Note) 
> 
> Registration Length 
> 
: Registration 
n 
ac aac ee 
GFI — Coded '0001' (modulo 8) or '0010' (modulo 128) 
Note: The figure is drawn assuming the total number of address 


digits present is odd. 


Figure 5-20. REGISTRATION CONFIRMATION Packet Format 


« Cause Field 
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Octet 4 is the cause field and contains the cause of the failure in 
negotiation of facilities or an indication that the registration field 
was verified by the DCE. 


The coding of the cause field in the 
REGISTRATION CONFIRMATION packet is shown in Table 21. 


le 21: Coding of the Cause field in 
REGISTRATION CONFIRMATION Packets 


8765 4321 


Registration/Cancellation Confirmed 9L11.-Piid 


Invalid Facility Request 0000 0011 
Local Procedure Error | , 0001 0011 


Network Congestion 0000 0101 


e Diagnostic Code 


Octet 5 is the diagnostic code and contains additional information 
on the reason for the failure of facilities registration. 


Appendix E lists the coding for diagnostics. The bits of the diag- 
nostic code are all set to ‘0’ when negotiation is successful, or 
when no additional information is supplied. 


Address Length Fields 


Octet 6 consists of the field length indicators for the DTE and DCE 
addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE (or 
remote DTE if DIE/DTE) address in semi-octets. Bits 8, 7, 6 and 5 
indicate the length of the DTE address in semi-octets. Each 
address length indicator is binary coded and bit 1 or bit 5 is the 
low order bit of the indicator. 


These fields are coded with all zeros under the procedures of this 
specification. 


Address Field 


Octet 7 and the following octets consist of the DCE address, when 
present, and the DTE address, when present. 


Each digit of an address is coded in a semi-octet in binary coded 
decimal with bit 5 or bit 1 being the low order bit of the digit. 


Starting from the high order digit, the address is coded in octet 7 
and consecutive octets with two digits per octet. In each octet, the 
higher order digit is coded in bits 8, 7, 6 and 5. 


The address field shall be rounded up to an integral number of 
octets by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the 


field when necessary. 


This field is not present under the procedures in this specification. 


e Registration Length Field 


The octet following the address field indicate the length of the reg- 
istration field in octets. The registration length indicator is binary 
coded and bit 1 is the low order bit of the indicator. 


Registration Field 


The registration field is used to indicate which optional user facili- 
ties are available, and which are currently in effect. 


The coding of the registration field is defined in § 7.3. 


The registration field contains an integral number of octets. The 
actual maximum length of this field depends on the network. 
However, this maximum does not exceed 109 octets. 
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6.1 On-Line Facility Registration 


On-Line Facility Registration is an optional user facility agreed upon for a 
period of time. This facility, if subscribed to, permits the DTE at any time 


~ to request registration of facilities, or obtain current values of facilities as 


understood by the DCE, by transferring across the DTE/DCE interface a 
REGISTRATION REQUEST packet. In a DTE/DTE environment, separate 
agreement to use this facility is required for each direction of registration- 
procedure initiation. For initiation of the registration procedure in a given 
direction, use of this facility permits the initiating DTE to transmit 
REGISTRATION REQUEST packets and requires the responding DTE to 
process received REGISTRATION REQUEST packets, as described below. 
In a DTE/DCE environment, the DTE is always the initiator of the registra- 
tion procedure while the DCE is always the responder. 


6.1.1 General Procedures for On-Line_Facility_Registration 


This section describes the general procedures for using the 

On-Line _Facility_ Registration Facility. The registration procedure itself 
does not affect the state of any logical channel. Specific procedures 
depend on the facility to be negotiated and are discussed in Section 6.1.2. 


6.1.1.1 Requesting Facility Registration 


This section applies to a DTE only when it acts as an initiator for the regis- 
tration procedure. 


A DTE requests registration of optional user facilities and/or obtains the 
current values of optional user facilities, as applicable, by transmitting 
across the interface a REGISTRATION REQUEST packet and by starting 
the Registration Request Response Timer (128). 


A REGISTRATION REQUEST packet may be sent without attempting to 
register any optional user facilities (1. e., without a Registration Field) to 
obtain the current values of the applicable optional user facilities or to 
avoid requesting facilities or values of facilities that are not available. 


Having sent a REGISTRATION REQUEST packet, the DTE should wait for 
the REGISTRATION CONFIRMATION packet before sending a 
CALL REQUEST packet. 


The failure to receive a REGISTRATION CONFIRMATION packet before 
expiration of T28 after transmission of a REGISTRATION REQUEST packet 
is considered an error. The registration procedure is retried up to a 
maximum number of times R28. After this, the Packet Layer notifies the 
appropriate entity that it has not received a confirmation of the registra- 
tion procedure. 
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This section always applies to a DCE when the registration procedure is 
used. It applies to a DTE only in a DTE/DTE environment when it acts as a 
responder for the registration procedure. 


The DCE or DTE will, in response to a REGISTRATION REQUEST packet 
(even if the packet has no Registration field), report the availability and 


the current value of all facilities applicable to the interface, by transferring 


a REGISTRATION CONFIRMATION packet across the interface. Optional 
facilities which are not offered by the network will not be reported in the 
REGISTRATION CONFIRMATION packet. 


When a REGISTRATION CONFIRMATION packet is returned, the facilities 
values shown are in effect for any subsequent virtual calls. The values of 
the Extended Packet Sequence Numbering, Packet Retransmission and 
D-bit Modification facilities and the allocation of logical channel type 
ranges can be modified only when there are no virtual calls (i.e., all 
logical channels used for virtual calls are in state p1). When these facili- 
ties take effect and when there is one or more logical channels assigned 
to permanent virtual circuits, a restart procedure is initiated. Ina 
DTE/DCE environment, the DCE transmits a RESTART_INDICATION packet 
with a cause indicating “Registration/Cancellation Confirmed” and the 
diagnostic “No Additional Information” in order to change the values for 
the permanent virtual circuits at the interface. At the remote end of each 
permanent virtual circuit, the corresponding RESET INDICATION packet is 
sent by the DCE with the cause “Remote DTE Operational” and the diag- 
nostic “No Additional Information.” In a DTE/DTE environment, the DTE 
transmitting a REGISTRATION CONFIRMATION packet also transmits a 
RESTART REQUEST packet with a cause indicating “DTE Originated” and 
the diagnostic “Registration/Cancellation. Confirmed.” 


If a requested value of a particular facility is not allowed, the DCE or DTE 
(DTE/DTE environment) shall report in the 
REGISTRATION CONFIRMATION packet: 


e if the facility has a Boolean value, the value allowed; 


e if the value is greater than the maximum allowed value of that facility, 
the maximum allowed value; or, 


e if the value is less than the minimum allowed value of that facility, the 
minimum allowed value. 


The REGISTRATION CONFIRMATION packet shall also contain an appro- 
priate cause code. The DTE may choose to accept the value reported by 
the DCE or to attempt to negotiate another value for the requested facility. 


If the DCE cannot make all the modifications requested in a 
REGISTRATION REQUEST packet, it will not alter the values of some facil- 
ities. Circumstances in which the DCE cannot make all of the modifica- 
tions requested include: 


e conflict in facilities settings; and, 


e when the interface has at least one virtual call established when 
attempting to negotiate those facilities that require all virtual call 
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logical channels to be in State p1 (including the collision of an 
INCOMING CALL packet and a REGISTRATION REQUEST packet). 


The DTE should wait for the REGISTRATION CONFIRMATION packet 
before sending a CALL REQUEST packet, or sending a packet on a per- 
manent virtual circuit. 


For every optional user facility, Appendix F, “On-Line Registration Facility 
Applicability” indicates: 


¢ if the value of the facility may be negotiated; 


e if REGISTRATION CONFIRMATION packets indicate whether or not 
the facility is supported by the DCE; and, 


e if the value of the facility may be altered by the DTE only when 
every logical channel used for virtual calls Is in state p1 or in any 
packet layer state. 


Indication in REGISTRATION CONFIRMATION packet of whether NUI over- 
ride facility is supported by the networks is for further study by the CCITT. 


A fault condition within the network may affect the facilities previously 
negotiated by means of REGISTRATION packets. In this situation the DCE 
initiates a restart procedure to inform the DTE of the failure. 


A restart procedure initiated by the DTE does not affect the facilities 
values. When the DCE initiates the restart procedure with the cause 
“Local Procedure Error,” the facilities values are not affected. When the 
DCE initiates the restart procedure with the cause “Network Congestion” 
or “Network Operational,” the values of facilities previously negotiated 
may be affected. When the DCE initiates the restart procedure with the | 
cause “Registration/Cancellation Confirmed,” the facilities values are as 
set by the related registration procedure. 


lf in a DTE/DTE environment, a DTE receives a REGISTRATION REQUEST 
packet after having transmitted its own REGISTRATION REQUEST packet, 
then the registration procedure is considered cancelled with no effect and 
no REGISTRATION CONFIRMATION packet is returned. The DTE may 
transmit another REGISTRATION REQUEST packet after some randomly 
chosen time delay. 


6.1.1.3 Receiving a Response to Facility Registration 


This section applies to a DTE only when it acts as an initiator for the regis- 
tration procedure. 


The REGISTRATION CONFIRMATION packet received in response to a 
REGISTRATION REQUEST packet, which was sent either with or without a 
Registration Field, always contains information regarding the availability 
and the current values of all optional user facilities applicable to the inter- 
face. The DTE may choose either to accept the values reported in this 
packet or to attempt to negotiate other values by transmitting another 
REGISTRATION REQUEST packet across the interface. 


The facility values reported in a REGISTRATION CONFIRMATION packet 
are in effect for any subsequent virtual calls. In addition, when there is 
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one or more Permanent Virtual Circuits at the interface, the values of 
those facilities that can be modified only when there are no existing 
virtual calls (i. e., all logical channels used for virtual calls are in the 
READY state - p1) take effect at the completion of a restart procedure. In 
a DTE/DCE environment, the DTE will also receive a 

RESTART INDICATION packet from the DCE with a cause indicating 
“Registration/Cancellation Confirmed” and the diagnostic “No Additional 
Information.” In a DTE/DTE environment, the DTE receiving a- 
REGISTRATION CONFIRMATION packet will also receive a | 
RESTART_INDICATION packet with a cause indicating “DTE Originated” 
and the diagnostic “Registration/Cancellation Confirmed.” In either case, 
a RESTART CONFIRMATION packet is transmitted in response to the 
RESTART_INDICATION packet. 


Those optional user facilities for which a modification was requested in 
the REGISTRATION REQUEST packet but for which there is no corre- 
sponding facility indicated in the REGISTRATION_CONFIRMATION packet 
are not supported or are not permitted to be negotiated with the 

On-Line Facility Registration Facility. | 


6.1.1.4 Effects of Fault Conditions on Registration 


A fault condition in a DTE that acts as an initiator for the registration pro- 

cedure may affect the values of the optional user facilities previously reg- 

istered through the registration procedure. In this case, the DTE should 

transmit a REGISTRATION REQUEST packet without a Registration Field 

to ascertain the current values of the optional user facilities as understood 

by the interfacing DCE (or DTE if DTE/DTE). : 


A fault condition within the network may affect the values of the optional 
user facilities previously registered through the registration procedure. In 
this case, the DCE initiates a restart procedure to inform the DTE of the 
failure. When the DCE initiates a restart procedure with the cause 
“Network Congestion” or “Network Operational”, the facilities values pre- 
viously negotiated may be affected. (When the DCE initiates a restart pro- 
cedure with the cause “Local Procedure Error”, the facilities are not 
affected. 


A fault condition within a DTE that acts as a responder for the registration 
procedure in a DTE/DTE environment may affect the values of the optional 
user facilities previously registered through the registration procedure. In 
this case, the DTE initiates a restart procedure with a cause of “DTE 
Originated” to inform the other DTE of the failure. If the diagnostic is 
“DTE Operational” or “DTE Not Operational”, then the facilities values 
previously negotiated may be affected; otherwise the facilities values are 
not affected. 


When a DTE that acts as an initiator for the registration procedure 
receives a RESTART_INDICATION packet indicating that the facilities 
values may have been affected, it should send a 

REGISTRATION _REQUEST packet without a Registration Field to jevity the 
facilities values previously negotiated. A second 

REGISTRATION REQUEST packet may be sent, if necessary to negotiate \ 
particular facilities. 
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6.1.2 Registration Procedures for Specific Optional User Facilities 
The registration procedure for a specific optional user facility depends on 
the facility. Table 21-A classifies, for the purposes of registration, the 
optional user facilities according to the registration-procedure require- 
ments applying to them. 


The absence of a registration-facility in a REGISTRATION REQUEST 
packet means no modification to the previous agreement is desired for the 
concerned facilities. 


The absence of a registration-facility in a REGISTRATION CONFIRMATION 


packet means that the concerned facilities are not supported or are not 
permitted to be negotiated with the On-Line Facility Registration Facility. 
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TABLE 21-A Part 1 of 2 
CLASSIFICATION OF OPTIONAL USER FACILITIES FOR REGISTRATION 


Registration Facility Used In: 
REGVREQ.* 
Packet To |Packet To 

‘Request | Indicate | Indicate 
Values For] Current Facility 
Facilities] Values of} Available 
Facilities 


Class And 
Characteristics Of 
Optional User 
Facilities (Note 1) 
(Reference Section) 


Packet To 


Optional User 
Facility 
(Note 2) 


On-line Facility 
Registration 
Closed User Group 
Related Facilities 
Bilateral Closed 
User Group 
Related Facilities 
Fast Select 
Network User Ident. 
RPOA Selection (per— 
interface basis) 
Hunt Group 
Call Redirection 
Call Redirection 
Notification 
Transit Delay Selec— 
tion & Indication 


Class 1: facilities 
for which registration 
does not apply 
(SECULON Och 2.) 2) 


Local Charging 
Prevention 


iClass 2: facilities 
ithat cannot be 
inegotiated but whose 
values can be ascer- 
tained 

(Section 6.1.2.3) 


iClass 3: facilities Reverse Charging No 
that apply on a per |Charging Info (per 

virtual call basis and} virtual call) No 
whose availability canj/RPOA Selection (per 

be ascertained by a virtual call) No 
DTE (these correspond |Called Line Address 

to certain Additional Modi fied No 


facilities that a DTE | Notification 
Imay use with no need 
for prior agreement) 


Section 6.12223) 
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Applicable 
to DTE\DTE 
Operation? 
(Note 4) 
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TABLE 21-A_ Part 2 of 2 
CLASSIFICATION OF OPTIONAL USER FACILITIES FOR REGISTRATION 


Registration Facility Used In: 
REG.REQ.* |REG.CONF.*|REG.CONF.*|Registration 

Packet To |Packet To |Packet To | Applicable 

Optional User Request | Indicate | Indicate | to DTE\DTE 
Facility Values For] Current Facility | Operation? 
(Note 2) Facilities] Values of} Available} (Note 4) 
Facilities| In DCE 


Class And 
Characteristics Of 
Optional User 
Facilities (Note 1) 
(Reference Section) 


Class 4: facilities Incoming Calls 


that are always avail-| Barred . 
able & whose use can |Outgoing Calls 
be invoked/revoked by Barred 


Flow Control Parm 
Negotiation 
Throughput Class 
Negotiation 
Fast Select 
Acceptance 


a DIE at any time 
(these correspond to 
Icertain Essential 
facilities whose use a 
DTE & DTE must agree 
to for a period of 
time) (Section 6.1.2.4) 


Class 5: facilities {Reverse Charging 
that apply to the | Acceptance C 
interface & whose Charging Info fner— 
availability for nego-| interface basis) C 
tiation can be ascer— |Nonstandard Default | 
tained & a value Packet Sizes | e 
negotiated (these Nonstandard Default 
correspond to certain Window Sizes f 
Additional facilities |Default Throughput 
whose use a DTE & DCE Classes Assignment | g 
must agree to for a |Logical Channel N 
period of time) Ranges (Note 2) o Uh 
(Section. 6:1.2.5) Extended Packet t 
Sequence Numbering| e d 


Packet Retransmiss. d 
D—bit Modification 5 d 


* REG.REQ = REGISTRATION REQUEST packet 
* REG.CONF = REGISTRATION CONFIRMATION packet 


1. The categorization of facilities as Essential or Additional is given in 
Table 9. 


2. In this section, the term “optional user facility” includes Logical 
Channel Ranges parameters. These parameters are inclusive of the 
One-way_Logical Channel Outgoing and | 
One-way_Logical Channel Incoming Facilities. The values subject to 
negotiation are the associated parameters (i. e., boundary points) of 
the one-way incoming logical channels (LIC and HIC), two-way logical 
channels (LTC and HTC), and one-way outgoing logical channels (LOC 
and HOC). 
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3. The registration procedure makes use of eight “registration-facilities.” 
These registration-facilities, which are used only in support of the reg- 
istration procedure, are: 


a. 
b. 


Cc: 


the “Non-negotiable Facilities Values” Registration-Facility: 
the “Availability Of Facilities” Registration-Facility; 


the “Facilities That May Be Negotiated At Any Time” Registration- 
Facility; | 


. the “Facilities That May Be Negotiated Only When All Logical 


Channels Used For Virtual Calls Are In State p1” Registration 
Facilities; | 


. the “Nonstandard Default Packet Sizes” Registration Facilities; 


the “Nonstandard Default Window Sizes” Registration Facilities: 


. the “Default Throughput Classes Assignment” Registration Facili- 


ties: 


. the “Logical Channel Types Ranges” Registration Facilities; 


The registration-facilities in (e), (f), and (g) above are used to 
negotiate the optional user facilities with the same name. 
However, the registration- facility is distinct from the optional user 
facility. 


4. “No” means that the corresponding bit in the registration-facility must 
be 0. 


5. Values for these facilities may be requested only when all logical 
channels used for virtual calls are in state p71. 


DTEs should ignore registration-facilities that they do not support or do 
not know. 


6.1.2.1 Class 1 Optional User Facilities 


The registration procedure does not apply to optional user facilities in 
Class 1. These optional user facilities are: 
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those facilities for which negotiation is not permitted: 


On-Line Facility_ Registration, 
Closed User Group Related Facilities, 
Bilateral Closed User Group Related Facilities, 
Network_User_lIdentification, and 


Hunt_Group; 


those facilities for which negotiation is not needed (these are Essential 
facilities that a DTE may request on a per virtual call basis at any 
time): 


Fast Select, and 


Transit_Delay_Selection_And_Indication 


those facilities that only a DCE uses: 


Call_ Redirection or Call_ Deflection Notification; and 
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e those facilities for which the applicability of the registration procedure 
is for further study by CCITT: 


= RPOA Selection (per-interface basis), and 
— Call Redirection; and 


— Call Deflection Related Facilities. 


6.1.2.2 Use of Registration-Facilities Applicable to Class 2 Optional User 


Facilities 


There is one Class 2 optional user facility: Local_ Charging Prevention. 


The registration procedure can be used only to ascertain the values of 
Class 2 optional use facilities. It cannot be used to invoke or revoke these 
facilities. 


To ascertain the values of Class 2 optional user facilities, the DTE must 
transmit across the DTE/DCE interface a REGISTRATION REQUEST packet 
with or without any registration-facilities. The “Ncn-negotiable Facilities 
Values” Registration-Facility is used by the DCE in a 

REGISTRATION CONFIRMATION packet to specify the values of the Class 
2 optional user facilities. 


6.1.2.3 Use of Registration-Facilities Applicable to Class 3 Optional User 


Facilities 


1) Reverse Charging; 

2) Charging Information (per virtual call basis); 
3) RPOA_Selection (per virtual call basis); and 
4) Called _Line Address Modified Notification. 


The registration procedure can be used only to determine the availability 
for use of Class 3 optional user facilities. It is not used to invoke or 
revoke these facilities. 


To ascertain the availability for use of Class 3 optional user facilities, the 
DTE must transmit across the DTE/DCE interface 4 

REGISTRATION REQUEST packet with or without any registration facilities. 
The “Availability of Facilities” Registration-Facility is used by the DCE in a 
REGISTRATION CONFIRMATION packet to specify whether optional user 
facilities are available for use by the DTE. If this registration-facility indi- 
cates that a Class 3 optional user facility is available for use, then the DTE 
may request it on subsequent Virtual Calls. 


s 6.1.2.4 Use of Registration-Facilities Applicable to Class 4 Optional User 


5 
S 


S 


S 


Facilities 


There are five Class 4 optional user facilities: 


1) Incoming Calls Barred; 


3 


) 

2) Outgoing Calls Barred; 
) Flow_Controil_Parameter_Negotiation; 
) 


4) Throughput _Class Negotiation; and 
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5) Fast Select Acceptance. 


The “Facilities That May Be Negotiated At Any Time” Registration-Facility 
is used by a DTE in a REGISTRATION REQUEST packet to specify whether 
optional user facilities are to be invoked or revoked. {The 

REGISTRATION REQUEST packet transmitted across the interface may 
also contain other registration-facilities.) 


The “Facilities That May Be Negotiated At Any Time” Registration-Facility 
is used by the DCE or DTE in a REGISTRATION CONFIRMATION packet to 
specify whether optional user facilities are invoked or revoked. If this. 
registration-facility indicates that the Flow _Control_ Parameter Negotiation 
and/or Throughput_Class Negotiation Facilities are invoked, then the DTE 
may negotiate them on subsequent virtual calls. If this registration-facility 
indicates that the Incoming Calls Barred, Outgoing Calls Barred, and/or 
Fast Select_ Acceptance Facilities are invoked, then they are in effect for 
Subsequent virtual calls. 


Notes: 


Invocation/revocation of the Incoming Calls Barred and/or 
Outgoing Calls Barred Facilities does not alter the values of 
the parameters for ranges of logical channel types (LIC, HIC, 
LTC, HTC, LOC, and HOC). 


In a DTE/DTE environment, the registration procedure may be 
applied to the Incoming Calls Barred, Outgoing Calls Barred, 
and Fast_Select_Acceptance Facilities (these facilities do not 
usually apply in this environment). The 
Incoming Calls Barred and Outgoing Calls Barred Facilities 
may be invoked/revoked to control virtual call initiation on the 
DTE/DTE interface. Negotiation of the Fast_Select_Acceptance 
Facility may be used to determine the ability of both DTEs to 
support the Fast_Select_Acceptance Facility when used during 
virtual call setup. 


6.1.2.5 Use of Registration-Facilities Applicable to Class 5 Optional User 


There are eight Class 5 optional user facilities: 


1) Extended Packet _Sequence_ Numbering the exact method for 
negotiating this facility is being studied by the CCITT). (Class 
5.1); 


2) D-bit_Modification (Class 5.1); 
Packet_Retransmission (Class 5.1); 
Nonstandard Default_Packet_Sizes (Class 5.2); 
Nonstandard Default_Window_Sizes (Class 5.2); 


~“] 


Reverse Charging Acceptance (Class 5.1); and 


) 
6) Default_ Throughput Class Assignment (Class 9.2); 
8) 


Charging Information (per-interface basis) (Class 5.1). 


The set of logical channel range parameters (LIC, HIC, LTC, HTC, LOC, 
and HOC) is also included in Class 5.2. This set encompasses the 
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One-way Logical Channel Outgoing and 
One-way Logical Channel. Incoming Facilities. 


Notes: 


1. Class 5 optional user facilities are further categorized by whether 
they have a boolean value (Class 5.1) or a numeric value (Class 
5.2). 


2. In this section, “optional user facilities” also refers to the set of 
parameters associated with the different logical channel types. 


3. The registration procedure for the 
Nonstandard Default_ Packet Sizes, Assignment Facilities applies 
to the use of these facilities for virtual calls only. The registration 
procedure does not apply to the use of these facilities for Perma- 
nent Virtual Circuits. 


To ascertain the availability for negotiation of Class 5 optional user facili- 
ties, the DTE transmits across the interface a REGISTRATION REQUEST 
packet with or without any registration facilities. :+he “Availability Of 
Facilities” Registration-Facility is used by the DCE or DTE ina 
REGISTRATION CONFIRMATION packet to specify whether optional user 
facilities are available for negotiation by the DTE. If this registration- 
facility indicates that a Class 5 optional user facility is available for negoti- 
ation, then the DTE may negotiate a value for it in a subsequent 
REGISTRATION REQUEST packet. 


The procedure for registering a value for such a facility is dependent on 
whether the facility has a boolean value (Class 5.1) or a numeric value 
(Class 5.3). 


Note: 


A DTE may attempt to register a value for a Class 5 optional user 
facility without ascertaining whether it is available for negotiation. 


To register a value for one or more optional user facilities in this class, 
the DTE transmits across the interface a REGISTRATION REQUEST packet 
containing the appropriate registration-facilities as shown in Table 21-A. 
The appropriate registration-facilities, as indicated in Table 21-A, are used 
by the DCE or DTE (DTE/DTE interface) in a 

REGISTRATION CONFIRMATION packet to specify a value for each Class 
9 Optional user facility applicable to the interface. 


Registering Values for Class 5.1 (Boolean) Optional User Facilities 


The appropriate registration-facilities are used by a DIE in a 
REGISTRATION REQUEST packet to specify whether optional user 
facilities are to be invoked or revoked. (The 

REGISTRATION REQUEST packet transmitted across the interface may 
also contain other registration facilities.) 


The appropriate registration-facilities are used by the DCE or DTE ina 
REGISTRATION CONFIRMATION packet to specify whether optional 
user facilities are invoked or revoked. 


Registering Values for Class 5.2 (Numeric) Optional User Facilities 
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The appropriate registration-facilities are used in a 

REGISTRATION REQUEST packet to specify the numeric values that 
the DTE wishes to negotiate for the corresponding Class 5.2 optional 
user facilities. (The REGISTRATION REQUEST packet transmitted 
across the interface may also contain other registration-facilities). 


When using the “Logical Channel Types Ranges” Registration- 
Facility, the values to be negotiated are the parameters (i. e., 
boundary points) associated with the one-way incoming logical chan- 
nels (LIC and HIC), two-way logical channels (LTC and HTC), and 
one-way outgoing logical channels (LOC and HOC) as shown in 
Appendix A, “Logical Channel Ranges.” The relationships between 
LIC, HIC, LTC, HTC, LOC, and HOC shown in Figure 1 must be main- 
tained. When there are no one-way incoming logical channels, LIC 
and HIC are equal to zero. When there are no two-way logical chan- 
nels, LTC and HTC are equal to zero. When there are no one-way 
outgoing logical channels, LOC and HOC are equal to zero. In addi- 
tion, the “Logical Channel Types Ranges” Registration-Facility also 
indicates the total number of logical channels that the DTE wishes to 
user for virtual calls. This total is equal to the sum of the number of 
one-way incoming logical channels, two-way logical channels, and 
one-way outgoing logical channels. 


The appropriate registration-facilities are used by the DCE and DTE in 
a REGISTRATION CONFIRMATION packet to specify the values of the 
corresponding Class 5.2 optional user facilities. The relationship 
between the values of Class 5.2 optional user facilities, if any, ina _ 
REGISTRATION REQUEST packet and those in the 

REGISTRATION CONFIRMATION packet is as follows: 


e ifthe requested value is acceptable, then the requested value is 
shown; 


e if the requested value is greater than the maximum-permitted 
value of that facility, then the value shown is the maximum- 
permitted value; and 


e if the requested value is less than the minimum-permitted value of 
that facility, then the value shown is the minimum-permitted value. 


6.2 Extended Packet Sequence Numbering 


Extended Packet_Sequence Numbering is an optional user facility agreed 
upon for a period of time. It is common to all logical channels at the 
DTE/DCE or DTE/DTE interface. 


This user facility, if subscribed to, provides sequence numbering of 


packets performed modulo ‘128’. In the absence of this facility, the 
sequence numbering of packets is performed modulo ‘8’. 
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6.3 D Bit Modification 


D_Bit_Modification is an optional user facility agreed upon for a period of 
time. This facility applies to all virtual calls and permanent virtual circuits 
at the DTE/DCE interface. This facility is only intended for use by those 
DTEs implemented prior to the introduction of the D-bit procedure which 
were designed for operation on public data networks that support 
end-to-end Pr significance. It allows these DTEs to continue to operate 
with end-to-end Pr significance within a national network. 


For communication within the national network, this facility, when sub- 
scribed to: 


e will change from 0 to 1 the value of bit 7 of the GFI in all 
CALL REQUEST and CALL_ACCEPTED packets and the value of the 
D-bit in all DTE_DATA packets received from the DTE; and, 


« will set to ‘0° the value of bit 7 of the GFI in all INCOMING CALL and 
CALL CONNECTED packets, and the value of the D-bit in all | 
DCE DATA packets transmitted to the DTE. 


For international operation, conversion b) above applies and conversion a) 
above does not apply. Other conversion rules for international operation — 
are for bilateral agreement between Administrations. 


6.4 Packet Retransmission 


The Packet_Retransmission facility is not used in SNA environments. 


6.5 Incoming Cails Barred 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Incoming Calls Barred is an optional user facility agreed upon for a 
period of time. This facility applies to all logical channels at the DTE/DCE 
interface used for virtual calls. 


This user facility, if subscribed to, prevents incoming virtual calls from 
being presented to the DTE. The DTE may originate outgoing virtual calls. 


Notes: 
1. Logical channels used for virtual calls retain their full duplex capa- 
bility. 


2. Some Administrations may provide a capability that also allows a 
virtual call to be presented to the DTE only in cases where the 
called address is the address of the calling DTE (i. e., a DIE may 
place a virtual call to itself even though incoming calls are 
barred.) | 
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This optional user facility applies only to virtual call service in a DTE/DCE 
environment. ) 


Outgoing Calls Barred is an optional user facility agreed upon for a 
period of time. This facility applies to all logical channels at the DTE/DCE 
interface used for virtual calls. 


This user facility, if subscribed to, prevents the DCE from accepting out- 
going virtual calls from the DTE. DTEs may receive incoming virtual calls 
only. 


Note: 


Logical channels used for virtual calls retain their full duplex capa- 
bility. 


6.7 One-Way Logical Channel Outgoing 


One Way Logical Channel Outgoing is an optional user facility agreed 
upon for a period of time and is recommended for IBM SNA X.25 DTEs 
that support multiple virtual circuits. This user facility, if subscribed to, 
restricts the logical channel use to originating outgoing virtual calls only. 


Note: 


A logical channel used for virtual calls retains its full duplex capa- 
bility. 


The rules according to which logical channel group numbers and logical 
channel numbers can be assigned to one-way outgoing logical channels 
for virtual calls are given in Appendix A, “Logical Channel Ranges.” 


Note: 


If all the logical channels for virtual calls are one-way outgoing at 
a DTE/DCE or DTE/DTE interface, the effect is equivalent to the 
Incoming Calls Barred facility (except that Note 2 of § 6.5 does not 


apply). 


6.8 One-Way Logical Channel Incoming 


One_Way_ Logical Channel Incoming is an optional user facility agreed 
upon for a period of time. This user facility, if subscribed to, restricts 
logical channel use to receiving incoming virtual calls only. This facility is 
recommended for IBM SNA X.25 DTEs that support multiple virtual circuits. 


Note: 


A logical channel used for virtual calls retains its full duplex capa- 
bility. 


The rules according to which logical channel group numbers and logical 
channel numbers can be assigned to one-way incoming logical channels 
for virtual calls are given in Appendix A, “Logical Channel Ranges.” 
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Note: 


If all logical channels for virtual calls are one-way incoming ata 
S DTE/DCE or DTE/DTE interface, the effect is equivalent to the 
Outgoing Calls Barred facility (see § 6.6). 


6.9 Non-Standard Default Packet Sizes 


Non Standard Default_Packet_Sizes is an optional user facility agreed 
upon for a period of time. The ability to select this facility must be pro- 
vided by IBM SNA X.25 DTEs. This facility, if subscribed to, provides for 
the selection of default packet sizes from the list of packet sizes supported 
by the Administration. Some networks may constrain packet sizes to be 


S the same for each direction of data transmission across the DTE/DCE or 
S DTE/DTE interface. The default packet size used by a DTE should always 
S. « be capable of being set to 128. In the absence of this facility, default 


packet sizes are ‘128 octets. 
Note: 


In this section, the term “packet sizes” refers to the maximum 
User_Data field lengths of DCE_DATA and DTE_DATA packets. 


Values other than the default packet sizes may be negotiated for a virtual 
call, on a per call basis, by means of the flow control parameter negoti- 
ation facility (see § 6.12), which may be implemented in IBM SNA X.25 
Dies. Vatues other than the defauii packet sizes may be agreed tora 
period of time for each permanent virtual circuit. 


6.10 Non-Standard Default Window Sizes 


Non-Standard Default_Window_Sizes is an optional user facility agreed 
upon for a period of time. The ability to select this facility must be pro- 
vided by IBM SNA X.25 DTEs. This user facility, if subscribed to, provides 
for the selection of default window sizes from the list of window sizes sup- 
ported by the Administration. Some networks may constrain the default 
window sizes to be the same for each direction of data transmission 

S across the DTE/DCE or DTE/DTE interface. The default window size used 

S by a DTE should always be capable of being set to 2. In the absence of 
this facility, the default window sizes are two (2). 


Values other than the default window sizes may be negotiated for virtual 
calls, on a per call basis, by means of the Flow Control Parameter Negoti- 
ation facility (see § 6.12), which is recommended for implementation by 
IBM SNA X.25 DTEs. Values other than the default window sizes may be 
agreed upon for a period of time for each permanent virtual circuit. 


6.11 Default Throughput Classes Assignment 


Default Throughput Classes Assignment is an optional user facility agreed 
upon for a period of time. This user facility, if subscribed to, provides for 
the selection of default throughput classes from the list of throughput 
classes supported by the Administration. Some networks may constrain 
the default throughput classes to be the same for each direction of data 
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transmission. In the absence of this facility, the default throughput 
classes correspond to the user class of service of the DTE (see § 7.2.2.2). 
In a DTE/DCE environment, they may not exceed the maximum throughput 
class supported by the network. 


The default throughput classes are the maximum throughput classes 
which may be associated with any virtual call at the DTE/DCE or DTE/DTE 
interface. Values other than the default throughput classes may be nego- 
tiated for a virtual call by means of the Throughput Class Negotiation 
facility (see § 6.13). Values other than the default throughput classes may 
be agreed upon for a period of time for each permanent virtual circuit. 


Note: 


Throughput characteristics and throughput class are described in 
Section 4.4.2. — : 


6.12 Flow_Control_ Parameter Negotiation 


This optional user facility applies only to virtual call service. 


Flow_Control_ Parameter Negotiation is an optional user facility agreed 
upon for a period of time which can be used by a DTE for virtual calls. 

The ability for the DTE to select this facility is recommended for IBM SNA 
X.25 DTEs. This facility, if subscribed to, permits negotiation, on a per call 
basis, of flow control parameters. The flow control parameters considered 
are the packet and window sizes at the DTE/DCE or DTE/DTE interface for 
each direction of data transmission. 


Note: 


In this section, the term “packet sizes” refers to the maximum 
User Data field lengths of DCE DATA and DTE_DATA packets. 


In the absence of the Flow_Control_ Parameter_Negotiation facility, the 
flow control parameters to be used at a particular DTE/DCE interface are 
the default packet sizes (see § 6.9) and the default window sizes (see § 
6.10). 


When the calling DTE has subscribed to the 

Flow_Control_ Parameter Negotiation facility, it may separately request, in 
the CALL _ REQUEST packet, packet sizes and/or window sizes for both 
directions of data transmission (see §§ 7.2.1 and 7.2.2.1). If particular 
window sizes are not explicitly requested in a CALL_ REQUEST packet, the 
DCE {or DTE for DTE/DTE) will assume that the default window sizes were 
requested for both directions of data transmission. If particular packet 
sizes are not explicitly requested, the DCE (or DTE for DTE/DTE) will 
assume that the default packet sizes were requested for both directions of 
data transmission. 


When a called DTE has subscribed to the 

Flow_Control_ Parameter Negotiation facility, each INCOMING CALL 
packet indicates the packet and window sizes from which negotiation can 
start (in a DTE/DTE environment, such an indication is present only if the 
calling DTE has provided it in its CALL REQUEST packet). No relationship 
needs to exist between the packet sizes (P) and window sizes (W) 
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requested in the CALL REQUEST packet and those indicated in the 
INCOMING CALL packet (except in a DTE/DTE environment where the 
CALL REQUEST and INCOMING CALL packets are really the same 
packet). The called DTE may request window and packet sizes with facili- 
ties in the CALL_ ACCEPTED packet. The only valid facility requests in the 
CALL_ACCEPTED packet, as a function of the facility indications in the 
INCOMING CALL packet, are given in Table 22. If the facility request is 
not made in the CALL_ACCEPTED packet, the DTE is assumed to have 
accepted the indicated values (regardless of the default values) for both 
directions of data transmission. In a DTE/DTE environment, if no facility 
indication was present in the INCOMING CALL packet and no facility 
request is made in the CALL_ACCEPTED packet, then the called DTE is 
assumed to have accepted the default values. 


Table 22: Valid facility requests in CALL ACCEPTED packets in 
response to facility indications in INCOMING CALL packets 


Facility Indication Valid Facility Request 


W (indicated) a2 W (indicated) = W (requested) 2 2 
W (indicated) = W (requested) = 1 or 2 


N ! 
P (indicated) 2 128 P (indicated) = P (requested) = 128 
P (indicated) < 128 128 = P (requested) 2 P (indicated) 


In a DTE/DCE environment, when the calling DTE has subscribed to the 
Flow _Control_ Parameter Negotiation facility, every CALL CONNECTED 
packet indicates the packet and window sizes to be used at the DTE/DCE 
interface for the call. In a DTE/DTE environment, absence of a facility indi- 
cation in the CALL_CONNECTED packet indicates that the called DTE has 
accepted the values in the INCOMING CALL packet or, if none, the default 
values. The only valid facility indications in the CALL CONNECTED 
packet, as a function of the facility requests in the CALL_REQUEST packet, 
are given in Table 23. 


Table 23: Valid facility indications in CALL CONNECTED packets in 
response to facility request in CALL REQUEST packets 


Facility Request | Valid Facility Indication | 


W (requested) = 2 W (requested) 2 W (indicated) 2 2 
W (requested) = 1 W (indicated) = 1 or 2 


P (requested) 2 128 P (requested) 2 P (indicated) = 128 
P (requested) < 128 128 = P (indicated) = P (requested) 


The network may have constraints requiring the flow control parameters 
used for a call to be modified before indicating them to the DTE in the 
INCOMING CALL packet or CALL_CONNECTED packet; e.g., the ranges of 
parameter values available on various networks may differ. 
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Window and packet sizes need not be the same at each end of a virtual 
call. 


The role of the DCE in negotiating the flow control parameters may be 
network dependent. 


6.13 Throughput Class Negotiation 


This optional user facility applies only to virtual call service. 


Throughput Class Negotiation is an optional user facility agreed upon for 
a period of time which can be used by a DTE for virtual calls. This facility, 
if subscribed to, permits negotiation, on a per call basis, of the throughput 
classes; and, should be supported by IBM SNA X.25 DTEs that support 
multiple virtual circuits. The throughput classes are considered independ- 
ently for each direction of data transmission. 


In a DTE/DCE environment, default values are agree.J between the DTE 
and the Administration (see § 6.11). The default values correspond to the 
maximum throughput classes which may be associated with any virtual 
call at the DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput_Class Negotiation 
facility, it may request the throughput classes of the virtual call in the 
CALL REQUEST packet for both directions of data transmission (see §§ 
7.2.1 and 7.2.2.2). If particular throughput classes are not explicitly 
requested, the DCE will assume that the default values were requested for 
both directions of data transmission. 


When a called DTE has subscribed to the Throughput_Class Negotiation 
facility, each INCOMING CALL packet will indicate the throughput classes 
from which DTE negotiation may start (in a DTE/DTE environment, such an 
indication is present only if the calling DTE has provided it in its 

CALL REQUEST packet). These throughput classes are lower or equal to 
the ones selected by the calling DTE, either explicitly or by default if the 
calling DTE has not subscribed to the Throughput Class Negotiation 
facility or has not explicitly requested throughput class values in the 

CALL REQUEST packet. In a DTE/DTE environment, the called DTE should 
assume that the default throughput classes were requested if no indi- 
cation is present in the INCOMING CALL packet. In a DTE/DCE environ- 
ment, the throughput classes indicated to the called DTE will also not be 
higher than the default throughput classes, respectively, for each direction 
of transmission, at the calling and the called DTE/DCE interfaces. They 
may be further constrained by internal limitations of the network. 


The called DTE may request with a facility in the CALL ACCEPTED packet 
the throughput classes that should finally apply to the virtual call. The 
only valid throughput classes in the CALL_ ACCEPTED packet are lower 
than or equal to the ones (respectively) indicated in the INCOMING CALL 
packet. If the called DTE does not make any throughput class facility 
request in the CALL_ ACCEPTED packet, the throughput classes finally 
applying to the virtual call will be the ones indicated in the 

INCOMING CALL packet. 
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In a DTE/DCE environment, if the called DTE has not subscribed to the 
Throughput Class Negotiation facility, the throughput classes finally 
applying to the virtual call are less than or equal to the ones selected at 
the calling DTE/DCE interface, and less than or equal to the default values 
defined at the called DTE/DCE interface. 


When the calling DTE has subscribed to the Throughput_Class Negotiation 
facility, every CALL CONNECTED packet will indicate the throughput 
classes finally applying to the virtual call. In a DTE/DTE environment, 
such an indication is present only if the called DTE has provided it in its 
CALL ACCEPTED packet; tn its absence, the calling DTE should assume 
the throughput classed requested in its CALL REQUEST packet or, if none, 
the default throughput classes apply. 


In a DTE/DCE environment, when neither the calling DTE nor the called 
DTE has subscribed to the Throughput Class Negotiation facility, the 
throughput classes applying to the virtual call will not be higher than the 
ones agreed as defaults at the calling and called DTE/DCE interfaces. 
They may be further constrained to lower values by the network, e.g., for 
international service. 


Notes: 


1. Since both Throughput Class Negotiation and 
Flow_Control_ Parameter Negotiation (see § 6.12) facilities can be 
applied to a single call, the achievable throughput will depend on 
how users manipulate the ‘D’ bit. 


2. Users are cautioned that the choice of too small a window and 
packet size at a DTE/DCE or DTE/DTE interface (made by use of 
the Flow_Control_ Parameter Negotiation facility) may adversely 
affect the attainable throughput class for a virtual call. This is like- 
wise true of flow control mechanisms adopted by the DTE to 
control data transmission from the DCE (or DTE if DTE/DTE). 
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6.14 Closed User_Group Related Facilities 


The optional user facilities in this section apply only to virtual call service 
in a DTE/DCE environment. The set of closed user group (CUG) optional 
user facilities enables users to form groups of DTEs to and/or from which 
access is restricted. Different combinations of access restrictions to 
and/or from DTEs having one or more of these facilities result in various 
combinations of accessibility. 


A DTE may belong to one or more CUGs. Each DTE belonging to at least 
one CUG has either: 


¢ the Closed User Group facility (see § 6.14.1) or 

e one or both of: 
— the Closed User Group with Outgoing Access, and/or 
— the Closed User _Group_with Incoming Access facilities 
(see §§ 6.14.2 and 6.14.3). 


For each CUG to which a DTE belongs, either or none of: 


e the Incoming Calls Barred within a Closed User Group; or 
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* the Outgoing Calls Barred _within_a_Closed_User_Group facilities. 
(see §§ 6.14.4 and 6.14.5) may apply for that DTE. Different combina- 
tions of CUG facilities may apply for different DTEs belonging to the 
same CUG. 


Depending on the CUG-related subscriptions and the number of CUGs that 
the DTE belongs to, a preferential CUG may also be required to be speci- 
fied by the DTE. Specification of a preferential CUG allows a CUG to be 
designated for a given virtual call without explicitly indicating it in a 

CALL REQUEST or INCOMING CALL packet. 


When a DTE belonging to one or more CUGs places a virtual call, the DTE 
may explicitly indicate in the CALL_REQUEST packet the CUG selected by 
using: 


e the Closed User Group Selection facility (see § 6.14.6): or 
¢ the Closed User Group with Outgoing Access Selection facility 
— (see § 6.14.7) (see Note). When a DTE belonging to one or more CUGs 
receives a virtual call, the CUG selected may be explicitly indicated tn 
the INCOMING CALL packet through the use of the 
Closed User Group Selection facility or the 
Closed User Group with Outgoing Access Selection facility. 


Note: 


For a given virtual call, only one of the above mentioned selection 
facilities can be present. 


The number of CUGs to which a DTE can belong is network dependent. 


6.14.1 Closed User_Group 
This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Closed User Group is an optional user facility agreed upon for a period of 
time for virtual calls. This user facility, if subscribed to, enables the DTE 
to belong to one or more closed user groups. A closed user group 
permits the DTEs belonging to the group to communicate with each other, 
but precludes communication with all other DTEs. 


When the DTE belongs to more than one closed user group, a preferential 
closed user group must be specified. 


When the Closed User Group facility is subscribed to, then only the 
Closed User Group Selection facility is applicable for use at the DTE/DCE 
interface. 


IBM SNA X.25 DTEs that support a single closed user group require no 


coding in the facilities field when the PSDN supports the assignment of a 
default user group. 
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6.14.2 Closed User_Group_ with Outgoing Access 
This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Closed User Group with Outgoing Access is an optional user facility 
agreed upon for a period of time for virtual calls. This user facility, if sub- 
scribed to, enables the DTE to belong to one or more closed user groups 
(as in § 6.14.1) and to originate virtual calls to DTEs in the open part of the 
network (i.e., DIES not belonging to any closed user group) and to DTEs 
belonging to other CUGs with the incoming access capability. 


When the Closed User Group with Outgoing Access facility is subscribed 
to and the DTE has a preferential CUG, then only the 

Closed User Group Selection facility (as in § 6.14.6) is applicable for use 
at the interface. 


When the Closed User Group _with Outgoing Access facility is subscribed 
to and the network offers to the DTE the capability of ee whether or 

not to have a preferential CUG {i.e., the 

Closed User Group with Outgoing Access Selection facility (see § 

6.14.7) is offered by the network), and the DTE has no preferential CUG, 

then both the Closed _User_Group_ Selection and the 

Closed User Group with Outgoing Access Selection facilities are appli- 

; cable for use at the interface. In all other cases of subscription to the 

Closed User Group With Outgoing Access facility, the DTE must specify 

a preferentiai CUG and oniy the Ciosed_ User Group Selection facility is 

applicable for use at the interface. 


6.14.3  Closed_User_Group_with_Incoming_Access 
This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Closed User Group with Incoming Access is an optional user facility 
agreed upon for a period of time for virtual calls. This user facility, if sub- 
scribed to, enables the DTE to belong to one or more closed user groups 
(as in § 6.14.1) and to receive incoming calls from DTEs in the open part of 
the network (i.e, DTEs not belonging to any closed user group) and from 
DTEs belonging to other CUGs with the outgoing access capability. 


When the Closed User_Group_with_Incoming Access facility is subscribed 
to and the DTE has a preferential CUG, then only the 
Closed User Group Selection facility is applicable for use at the interface. 


When the Closed_User_Group_with_Incoming Access facility is subscribed 
to and the network offers to the DTE the capability of choosing whether or 
not to have a preferential CUG (i.e., the 

Closed User_Group_with Outgoing Access facility is offered by the 
network), and the DTE has no preferential CUG, then both the 

Closed User Group Selection and the 

Closed User Group with Outgoing Access Selection facilities are appli- 
cable for use at the interface. 
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6.14.4 Incoming Calls _Barred_within_a_Closed_User_Group 
This optional user facility ‘applies only to virtual call service in a DTE/DCE 
environment. 


Incoming Calls Barred _within_a_ Closed User Group is an optional user 
facility agreed upon for a period of time. This user facility, if subscribed to 
for a given closed user group, permits the DTE to originate virtual calls to 
DTEs in this closed user group, but precludes the reception of incoming 
calls from other DTEs in this closed user group. 


6.14.5 Outgoing Calls Barred _within_a_Closed User Group 
This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Outgoing Calls Barred within a_ Closed User Group is an optional facility 
agreed upon for a period of time. This user facility, if subscribed to for a 
given closed user group, permits the DTE to receive virtual calls from 
DTEs in this closed user group, but prevents the DTE from originating 
virtual calls to DTEs in this closed user group. 


6.14.6 Closed User_Group_ Selection 
This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Closed User_Group_ Selection is an optional user facility which may be | 
used on a per virtual call basis. This facility may be requested or 
received by a DTE only if it has subscribed to the Closed User Group 
facility, or the Closed User Group with Outgoing Access facility and/or 
the Closed User-Group_with_Incoming Access facility. 


The Sinsed MixewG one Seleeich facility (see §§ 7.2.1 and 7.2.2.3) may 
be used by the calling DTE in the CALL REQUEST packet to specify the 
closed user group selected for a virtual call. 


The Closed User Group Selection facility is used in the INCOMING CALL 
packet to indicate to the called DTE the closed user group selected for a 
virtual call. 


The number of closed user groups to which a DTE can belong is network 
dependent. If the maximum value of the index used by the DTE to select 
the closed user group is 99 or less, the basic format of the 

Closed User _Group_ Selection facility must be used. If the value of the 
index is between 100 and 9999, the extended format of the 

Closed User Group Selection facility must be used. 


some networks may permit a DTE to use either the basic or extended 


format of the Closed User Group Selection facility when the index is 99 or 
less. 
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Note: 


When a DTE subscribes to less than 101 closed user groups, the 
network should be able to agree on a maximum value of the index 
smaller than 100 if requested by the DTE. 


The appearance in a CALL_REQUEST packet of both formats or a format 
inconsistent with the number of CUGs subscribed to will be treated as an 
error for which the network clears the call with a cause indicating “Invalid 
Facility Request.” 


The significance of the Closed User _Group_ Selection facility: 


e in CALL REQUEST packets is given in Table 24; and 
e in INCOMING CALL packets is given in Table 25. 


6.14.7 Closed User _Group_with Outgoing Access Selection 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Closed User Group _with Outgoing Access Selection is an optional user 
facility which may be used on a per virtual call basis. This facility may be 
requested by a DTE only if the network supports it and 


e the DTE has subscribed to the 
Closed User Group_with Outgoing Access facility or to both the 
— Closed User Groun with Outgoing Access and 
— Closed _User_Group_with_Incoming_ Access facilities. 


This facility may be received by a DTE only if the network supports it and 
the DTE has subscribed to the Closed User _Group_with_Incoming Access 
facility or to both the Closed User Group _with_Incoming Access and 
Closed User _Group_with Outgoing Access facilities. 


The Closed User_Group_ with Outgoing Access_ Selection facility (see §§ 
7.2.1 and 7.2.2.4) may be used by the calling DTE in the CALL REQUEST 

packet to specify the closed user group selected for a virtual call and to 

indicate that outgoing access Is also desired. 


The Closed User_Group with Outgoing Access_ Selection facility is used 
in the INCOMING CALL packet to indicate to the called DTE the closed 
user group selected for a virtual call and that outgoing access had applied 
at the calling DTE. 


The Closed User_Group_with Outgoing Access_Selection facility can only 
be present in the facility field of CALL SET-UP packets if the DTE does not 
have a preferential closed user group. 


The number of closed user groups to which a DTE can belong is network 
dependent. If the maximum value of the index used by the DTE to select 
the closed user group is 99 or less, the basic format of the 

Closed User Group With Outgoing Access Selection facility must be 
used. If the value of the index is between 100 and 9999, the extended 
format of the Closed User Group With Outgoing Access _ Selection facility 
must be used. 
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Table 24: Meaning 


Calling \ CALL REQUEST Packet 
\ Contents (2) 


DIE CUG 
Subscription (1) \ 


CUG w/Preferential 


CUG/IA w/Preferential CUG 
CUG/OA w/Preferential CUG 
CUG/IA/OA w/Preferential CUG 
CUG/IA w/o Preferential CUG © 
CUG/0OA w/o Preferential CUG 


CUG/TA/OA w/o Preferential CUG 


No CUG 


(#) Refer to Notes 


some networks may permit a DTE to use either the basic or extended 
format of the Closed User Group With Outgoing Access Selection facility 
when the index is 99 or less. 


Note: 


When a DTE subscribes to less than 101 closed user groups, the 
network should be able to agree on a maximum value of the index 
smaller than 100 if requested by the DTE. 


The appearance in a CALL REQUEST packet of both formats or a format 
inconsistent with the number of CUGs subscribed to will be treated as an 
error for which the network clears the call with a cause indicating “Invalid 
Facility Request.” 


The significance of the presence of the 
Closed User Group with Outgoing Access Selection facility; 


e in CALL REQUEST packets is given in Table 24 and in 
° in INCOMING CALL packets is given in Table 25. 


6.14.8 Absence of Both CUG Selection Facilities 


The significance of the absence of both the CUG Selection facility and 
the CUG with Outgoing Access Selection facility: 


e in CALL REQUEST packets is given in Table 24 and 
e in INCOMING CALL packets is given in Table 25. 


of Closed User Group Facility in CALL REQUEST Packets 


Neither 
CUG Selection 
Facility 


CUG 
Selection 
Facility 


CUG with OA 
Selection 
Facility 


Preferental or 
Only CUG 
(Note 4) \ 


CUG (3) 
CUG Specified (4) 


CUG Specified 
Plus OA 


(4) 


CUG 


NA (Call CLeared) 


Preferential or Qnly 
CUG plus OA 
(5 & 6) 


NA (Call Cleared) 


CUG Specified (4). CUG Speci fied 
| Plus OA 


(5 & 6) 


Outgoing Access 


NA (Call Cleared) NA (Call Cleared) 


Below CUG: Closed User Group IA: Incoming Access QA: Outgoing Access 
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Notes with reference to Table 24:: 
1. The order of subscription types is different than Table 25. 


2. The inclusion of both the Closed_User_Group_Selection facility 
and the Closed User Group_with Outgoing Access Selection 
facility is not allowed in the CALL REQUEST packet. 


3. CUG without preferential CUG is not allowed. 


4. if outgoing calis are barred within the specified CUG or within the 
preferential or only CUG, then the call is cleared. 


Q. If outgoing calls are barred within the specified CUG or within the 
preferential or only CUG, then only Outgoing Access applies. 


6. For international calls, if the destination network does not support 
the Closed User Group with Outgoing Access Selection facility, 
the call may be cleared even if the called DTE belongs to the 
specified closed user group or to the open world or has incoming 
aCCess. 


Table 25: Meaning of Closed User Group Facility in INCOMING CALL Packets 


Calling \INCOMING CALL Packet CUG CUG with OA Neither 
DTE CUG \ Contents Selection Selection CUG Selection 


Subscription (1) \ Facility Facility Facility 


Preferential or 
Only CUG 


(3) 


Preferential or 


CUG with Preferential CUG (2) 


CUG Specified (3) 


CUG/OA w/Preferential CUG 


CUG/IA w/Preferentail CUG CUG Speci fied Not Applicable 


CUG Spéecitied: (3) 


Plus IA Only CUG Plus IA © 
CUG/TA/OA w/Preferential CUG | (4) (5) 
CUG/OA w/o Preferential CUG | | Not Applicable 


CUG Speci fied 
Plus JA 
(4) Incoming Access 


| Not Applicable 


| (#) Refer to Notes Below CUG: Closed User Group IA: Incoming Access OA: Outgoing Access 


CUG/IA w/o Preferential CUG | 


CUG/IA/OA w/o Preferential CUG 


Not Applicable 


Notes with reference to Table 25:: 
1. The order of subscription types is different than Table 24. 
2. CUG without preferential! is not allowed. 


3. When incoming calls are barred within this CUG, the call is 
blocked; there is no incoming call. 


4. When.incoming calls are barred within this CUG, only incoming 
access applies and the INCOMING CALL packet carries neither 
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the Closed User Group Selection nor the 
Closed User _Group_ with Outgoing Access Selection facility. 


5. When incoming calls are barred within this CUG, only incoming 
access applies. | 


6.15 Bilateral_Closed User _Group Related Facilities 


The optional user facilities in this section apply only to virtual call service 
in a DTE/DCE environment. 


The set of bilateral closed user group (BCUG) optional user facilities 
enables pairs of DTEs to form bilateral relations allowing access between 
each other while excluding access to or from other DTEs with which such 
a relation has not been formed. Different combinations of access 
restrictions for DTEs having these facilities result in various combinations 
of accessibility. 


There are three BCUG-related facilities: two of these are facilities that 
each DTE and the network agree to for a period of time; the other facility 
permits the BCUG selected for a given virtual call to be indicated. The 
three facilities are: 


1) Bilateral Closed User Group: this is the basic facility that 
enables a DTE to belong to one or more BCUGs; 


2) Bilateral Closed User _Group_ With Outgoing Access: this is a 
variant of (a) that also enables the DTE to make outgoing calls 
to DTEs in the open part of the network (i. e., to DTEs not 
belonging to any BCUG); and 


3) Bilateral Closed User Group Selection: this facility provides 
for the specification of the BCUG pertaining to a specific 
virtual call. 


A DTE may belong to one or more BCUGs. Each DTE belonging to at least 
one BCUG has either the BCUG facility (see § 6.15.1) or the 

BCUG with Outgoing Access facility (see § 6.15.2). For a given BCUG, it 
is permissible for one DTE to subscribe to the BCUG facility while the 
other DTE subscribes to the BCUG with Outgoing Access facility. 


When a DTE belonging to one or more BCUGs places a virtual call, the 
DTE should indicate in the CALL_ REQUEST packet the BCUG selected by 
using the BCUG Selection facility (see § 6.15.3). When a DTE belonging to 
one or more BCUGs receives a virtual call, the BCUG selected will be 
indicated in the INCOMING CALL packet through the use of the 

BCUG Selection facility. 


The number of BCUGs to which a DTE can belong is network dependent. 


A DTE may, at the same time, have one of the facilities described in this 
section and one or more of the Closed User Group related facilities 
described in Section 6.16. The CUG and BCUG facilities are independent 
of one another. For example, a call within a CUG is not regarded as an 
outgoing access call in relation to the BCUG-related facilities. 
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6.15.1 Bilateral _ Closed User_Group 


Bilateral Closed User Groups are not allowed in SNA environments. 


6.15.2 Bilateral Closed User_Group_ with Outgoing Access 
Bilateral Closed User Groups with Outgoing Access are not allowed in 
SNA environments. 


6.15.3 Bilateral _ Closed User Group Selection 
Bilateral Closed User Groups and, thus, BCUG Selection are not allowed 
in SNA environments. 


6.16 Fast Select 


This optional user facility applies only to virtual call service. 


6.16.1 SNA-to-SNA Connections 
The possible use of the Fast Select facility on SNA-to-SNA connections is 
a subject for further study. 


6.16.2 SNA-to-non_SNA Connections 
Fast Select is an optional user facility which may be requested by a DTE 
for a given virtual call. In a DTE/DCE environment, a DTE may use this 
facility without prior agreement. In a VIE/DIE environment, prior agree- 
ment between the two DTEs is required to use this facility. Such an 
agreement permits both DTEs to originate calls with this facility and 
requires them to process received calls using this facility. 


If, in a DTE/DCE environment, a DTE places a call using Fast Select to a 
DTE that has not subscribed to the Fast_Select_Acceptance Facility, then 
the call will be cleared by the network with a cause indicating “Fast Select 
Acceptance Not Subscribed.” If, in a DTE/DTE environment, a DTE places 
a call to a DTE that did not agree to use Fast Select, then the called DTE 
may clear the call with a cause indicating “DTE Originated” and the diag- 
nostic “Fast Select_Not Subscribed.” 


DTEs can request the Fast_Select facility on a per call basis by means of 
an appropriate facility request (see §§ 7.2.1 and 7.2.2.10) ina 

CALL REQUEST packet using any logical channel which can be used for 
originating virtual calls. 


The Fast Select facility, if requested in the CALL REQUEST packet and if it 
indicates no restriction on response: 


¢ allows this packet to contain a Call User Data field of up to ‘128° 
octets, 

e authorizes the DCE (or DTE if DTE/DTE) to transmit to the calling 
DTE, during the DTE Waiting state, a 
— CALL CONNECTED packet with a Called User Data field, or 
— a CLEAR_INDICATION packet with a Clear _User Data field, 
of up to 128 octets, and 

e authorizes the calling DTE and the DCE (or DTE if DTE/DTE) to 
transmit after the call is connected, 
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— aCLEAR REQUEST packet or — 
— a CLEAR_INDICATION packet, 
respectively, with a Clear User Data field of up to ‘128’ octets. 


The Fast Select facility, if requested in the CALL_REQUEST packet and if it 
indicates restriction on response: 


¢ allows this packet to contain a call user data field of up to 128 
octets; and 

e authorizes the DCE (or DTE if DTE/DTE) to transmit to the calling 
DTE, during the DTE Waiting state, a clear indication packet with a 
clear user data field of up to 128 octets; the DCE would not be 
authorized to transmit a CALL_CONNECTED packet. 


When a DTE requests the fast select facility in a CALL_ REQUEST packet, 


the INCOMING CALL packet should only be delivered to the called DTE if 


that DTE has subscribed to the Fast Select_Acceptance facility (see 6.17). 


If the called DTE has subscribed to the Fast_Select_Acceptance facility, it 
will be advised that the Fast Select Facility, and an indication of whether 
or not there is a restriction on the response, has been requested through 
the inclusion of the appropriate facility (see §§ 7.2.1 and 7.2.2.6) in the 
INCOMING CALL packet. . 


If the called DTE has not subscribed to the Fast_Select_Acceptance 
facility, an INCOMING CALL packet with the Fast Select facility requested 
will not be transmitted and a CLEAR_INDICATION packet with the cause 
“Fast Select_Acceptance Not Subscribed” will be returned to the calling 
DTE. 


The presence of the Fast Select facility indicating no restriction on 
response in an INCOMING CALL packet permits the DTE to issue, as a 
direct response to this packet, a CALL. ACCEPTED packet with a 

Called User Data field of up to ‘128’ octets or a CLEAR REQUEST packet 
with a Clear User Data field of up to ‘128’ octets. If the call is connected, 
the DTE and the DCE are then authorized to transmit a CLEAR REQUEST 
or a CLEAR_INDICATION packet, respectively, with a Clear_User_ Data 


field of up to ‘128° octets. 


The presence of the Fast_Select facility indicating restriction on response 
in an INCOMING CALL packet permits the DTE to issue, as a direct 
response to this packet, a CLEAR REQUEST packet with a 

Clear User Data field of up to ‘128’ octets; the DTE would not be author- 
ized to send a CALL_ACCEPTED packet. 


Note: 


The Call User Data field, the Called User Data field and the 
Clear User Data field will not be fragmented for delivery across 
the interface. 


The significance of the CALL_ CONNECTED packet and the 
CLEAR_INDICATION packet with the cause “DTE originated” as a direct 
response to the CALL REQUEST packet with the Fast_Select facility is that 
the CALL REQUEST packet with the data field has been received by the 


called DTE. 
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All other procedures of a call in which the Fast Select facility has been 
requested are the same as those of a virtual call. 


6.17 Fast_Select_Acceptance 


This optional user facility applies only to virtual call service in a DTE/DTE 
environment. 


6.17.1 SNA-to-SNA Connections 
The possible use of the Fast_Select_Acceptance facility in SNA environ- 
ments is a subject for further study. 


6.17.2 SNA-to-non SNA Connections 
Fast_Select_Acceptance is an optional user facility agreed upon for a 
period of time. This user facility, if subscribed to, authorizes the DCE to 
transmit to the DTE INCOMING CALL packets which request the 
Fast Select facility. In the absence of this facility, the DCE will-not 
transmit to the DTE INCOMING CALL packets which request the 
Fast Select facility. 


If the called DTE has subscribed to the Fast Select_Acceptance Facility, it 
will be advised that Fast Select, as well as an indication of whether there 
is a restriction on the response, has been requested through the inclu- 
sion of the Fast Select Facility in the INCOMING CALL packet. 


The presence of the Fast Select Facility indicating no restriction on 
response in an INCOMING CALL packet permits the called DTE: 


e to issue, as a direct response to this packet, a CALL_ACCEPTED 
packet with a Called User Data Field of up to 128 octets; 


e to issue, at any time, a CLEAR REQUEST packet with a 
Clear User Data Field of up to 128 octets; and 


e to receive, after call setup has been completed, a CLEAR INDICATION 
packet with a Clear User Data Field of up to 128 octets. 


The presence of the Fast_Select Facility indicating restriction on response 
in an INCOMING CALL packet permits the called DTE to issue, as a direct 
response to this packet, a CLEAR REQUEST packet with a 

Clear User Data Field of up to 128 octets; the called DTE is not authorized 
to send a CALL_ACCEPTED packet. 


Note: 


The Call_User_Data field, Called User Data field and Clear_User Data 
field will not be fragmented for delivery across the interface. 


6.18 Reverse Charging 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Reverse Charging is an optional user facility which can be requested by a 
DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.6) to request that 
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charges for the call be made against the called DTE. This facility is 
recommended for IBM SNA X.25 DTEs. 


6.19 Reverse Charging Acceptance 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Reverse Charging Acceptance is an optional user facility agreed upon for 
a period of time for virtual calls. This user facility, if subscribed to, 
authorizes the DCE to transmit to the DTE INCOMING CALL packets which 
request the Reverse Charging facility. In the absence of this facility, the 
DCE will not transmit to the DTE INCOMING CALL packets which request 
the Reverse Charging facility. This facility is recommended for IBM SNA 
X.25 DTEs. 


Note: 


Not subscribing to this facility does not nece.isarily mean that the 
DCE will not transmit the Reverse Charging facility with the 
reverse charging not requested parameter to the DTE. 


6.20 Local Charging Prevention 
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This optional user facility applies only to virtual call service in a DTE/DCE | 
environment. 


Local Charging Prevention is an optional user facility agreed upon for a 
period of time for virtual calls. This user facility, when subscribed to, 
authorizes the DCE to prevent the establishment of virtual calls which the 
subscriber must pay for by: 


e not transmitting to the DTE incoming calls which request the 
Reverse Charging facility, and 


e insuring that the charges are made to another party whenever a call 
is requested by the DTE. This other party can be determined by using 
any of a number of actions, both procedural and administrative. Pro- 
cedural methods include: 


— the use of Reverse Charging, 
— identification of a third party using the NUL Subscription facilit 
(see § 6.21). 3 


When the party to be charged has not been established for a call request, 
the DCE that receives the CALL REQUEST packet will apply reverse 
charging to the call. 


Network_User_Identification (NUI) Related Facilities 


The optional user facilities in this section apply only to virtual call service 
in a DTE/DCE environment. 
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The set of Network_User Identification (NUI) related facilities enables the 
DTE to provide information to the network for purposes of billing, security, 
network management, or to invoke subscribed facilities. 


This set is composed of three optional user facilities. NUI Subscription 
facility (see § 6.21.1) and NUI Override facility (see § 6.21.2) may be 
agreed upon for a period of time for virtual calls. A DTE may subscribe to 
one or both of these facilities. When one or both of these facilities are 
subscribed to, one (or several) network user identifier is also agreed upon 
for a period of time. A given network user identifier may be either specific 
or common to NUI Subscription facility and NUI Override facility. The 
network user identifier is transmitted by the DTE to the DCE in the 

NUI Selection facility (see § 6.21.3). 


Network user identifier is never transmitted to the remote DTE. The 
calling DTE address transmitted to the remote DTE in the calling DTE 
address field should not be inferred from the network user identifier trans- 
mitted by the DTE in the NUI Selection facility in the CALL REQUEST 
packet. | 


6.21.1 NUI Subscription 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


NUL Subscription is an optional user facility agreed upon for a period of 
time for virtual calls. This facility, if subscribed to, enables the DTE to . 
provide information to the network for billing, security or network manage- 
ment purposes ona per call basis. This information is provided by the 
DTE in the CALL REQUEST packet or in the CALL_ACCEPTED packet by 
using the NUI_ Selection facility (see § 6.21.3). It may be used whether or 
not the DTE has also subscribed to the Local Charging Prevention facility 
(see § 6.20). If the DCE determines that the network user identifier is 
invalid or that the NUI Selection facility is not present when required by 
the network, it will clear the call as described in Appendix C, “Packet 
Layer DCE Actions.” © 


6.21.2 NUI_ Override 


This optional user facility applies only to virtual call service tn a DTE/DCE 
environment. 


NUIl Override is an optional user facility agreed upon for a period of time 
for virtual calls. When this facility is subscribed to, one or more network 
user identifiers are also agreed upon for a period of time. Associated 
with each network user identifier, is a set of subscription-time optional 
user facilities. When one of these network user identifiers is provided in a 
CALL REQUEST packet by means of the NUI Selection facility (see § 
6.21.3), the set of subscription-time optional user facilities associated with 
it overrides the facilities which apply to the interface. This override does 
not apply to other existing calls or subsequent calls on the interface. It 
remains in effect for the duration of the particular call to which it applies. 


The optional user facilities that may be associated with a network user 


identifier when the NUI Override facility has been subscribed to are speci- 
fied in Table 25a. The optional user facilities which have been agreed 
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upon for a period of time for the interface and which are not overridden by 
using the NUI Override facility remain in effect. 


Table 25a: Subscription-time Optional User Facilities that may be | May be 
associated with a Network User Identifier in Conjunction associated with 
with the NUI Override Facility a NUI override 


On-line facility registration 
Extended packet sequence numbering 
D bit modification 7 
Packet retransmission 
Incoming calls barred 
Outgoing calls barred 
One-way logical channel outgoing 
One-way logical channel incoming 
Non-standard default packet sizes 
Non-standard default window sizes 
Default throughput classes assignment 
Flow control parameter negotiation (subscription time) 
Throughput class negotiation (subscription time) 
Closed user group related facilities | 
Closed user group 
Closed user group with outgoing access 
Closed user group with incoming access 
Incoming calls barred within a closed user group 
Outgoing calls barred within a closed user group 
Bilateral closed user group related facilities 
Bilateral closed user group 
Bilateral closed user group with outgoing access 
Fast select acceptance 
Reverse charging acceptance 
Local charging prevention 
Charging information (subscription time) 
RPOA Selection 
Hunt group 
Call redirection and call deflection related facilities 
Call redirection 
Call deflection subscription 
TOA/NPI address subscription 


6.21.3 NUI Selection 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


NUL Selection is an optional user facility which may be requested by a 
DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.7), This user facility 
may be requested by a DTE only if it has subscribed to the 

NUL Subscription facility (see § 6.21.1.) or the NUI Override facility or both 
facilities. NUI Selection facility permits the DTE to specify which network 
user identifier is to be used in conjunction with the NUL Subscription 
facility or the NUI Override facility or both facilities. 
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NUL Selection may be requested in a CALL REQUEST packet if the 


selected network user identifier has been agreed upon in conjunction with 


the NUL Subscription facility or the NUL Override facility. In addition, it 
may be requested in a CALL _ ACCEPTED packet if the selected network 
user identifier has been agreed upon in conjunction with the 

NUL Subscription facility. 


Some networks may require that the NUI Selection facility be requested 
by the DTE in every CALL_REQUEST packet and, possibly, in every 
CALL ACCEPTED packet transmitted on a given DTE/DCE interface, when 


the NUI Subscription facility has been agreed upon for a period of time for 


the interface. 


If the network determines that the network user identifier is invalid or that 
any of the optional user facilities requested in the CALL REQUEST packet 
are not allowed for the DTE, it will clear the call. 


6.22 Charging_Information 


This optional user facility applies only to Virtual Call service in a DTE/DCE 
environment. 


Charging Information is an optional user facility which may be either 
agreed upon for a period of time or requested by the DTE for a given 
virtual call. 


If the DTE is the DTE to be charged, the DTE can request the 

Charging Information facility on a per call basis by means of an appro- 
priate facility request (see §§ 7.2.1 and 7.2.2.8.1) in a CALL REQUEST 
packet or CALL_ACCEPTED packet. 


If a DTE subscribes to the Charging Information facility for a contractual 
period, the facility is in effect for the DTE, whenever the DTE is the DTE to 
be charged. 


Using the CLEAR_INDICATION or DCE CLEAR CONFIRMATION packet, 
the DCE will send to the DTE information about the charge for that call 
and/or other information which makes it possible for the user to calculate 
the charge. 


, 6.23 RPOA Related Facilities 
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These optional user facilities apply only to Virtual Calls in a DTE/DCE 
environment. 


The set of RPOA optional user facilities provides for the calling DTEs des- 
ignation of a sequence of one or more RPOA transit network(s) within the 
originating country through which the call is to be routed when more than 
one RPOA transit network exists at a sequence of one or more gateways. 
In the case of international calls, this capability includes the selection of 
an international RPOA in the originating country. 
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6.24 Hunt_Group 


RPOA Subscription is an optional user facility agreed upon for a period of 
time for virtual calls. This user facility, if subscribed to, applies (unless 
overridden for a single virtual call by the RPOA_ Selection facility) to all 
virtual calls where more than one RPOA transit network exist at a 
sequence of one or more gateways. The RPOA_ Subscription facility pro- 
vides a sequence of RPOA transit networks through which calls are to be 
routed. In the absence of both the RPOA Subscription facility and 

RPOA_ Selection facility (see § 6.23.2), no user designation of RPOA transit 
networks is in effect. | 


6.23.2 RPOA Selection 


RPOA Selection is an optional user facility which may be requested by a 
DTE for a given virtual call (see §§ 7.2.1 and 7.2.2.9). It is not necessary to 
subscribe to the RPOA Subscription facility in order to use this facility. 
This facility, when used for a given virtual call, applies for this virtual call 
only where more than one RPOA transit network exist at a sequence of 
one or more gateways. The RPOA Selection facility provides a sequence 
of RPOA transit networks through which the call is to be routed. The 
presence of this facility in a call request packet completely overrides the 
sequence of RPOA transit networks that may have been specified by the 
RPOA Subscription facility (see § 6.23.1). 


If the DTE selects only one RPOA transit network, either the basic or 
extended format of the RPOA_ Selection facility may be used. If the DTE 
selects more than one RPOA transit network, the extended format of the 
RPOA Selection facility is used. The appearance of both formats in a 
CALL REQUEST packet will be treated as a facility code not allowed. 


To be in compliance with ANS X3.100: 
¢ All networks shall implement basic RPOA_ Selection. 


¢ Networks shall also provide extended RPOA Selection to DTEs 
that require it. 


This optional user facility applies only to virtual calls in a DTE/DCE envi- 
ronment. | 


Hunt _Group is an optional user facility agreed upon for a period of time. 
This user facility, if subscribed to, distributes INCOMING CALL packets 
having an address associated with the hunt_group across a designated 
grouping of DTE/DCE Interfaces. 


selection is performed for an incoming virtual call if there is at least one 
idle logical channel, excluding one-way outgoing logical channels, avail- 
able for virtual calls on any of the DTE/DCE interfaces in the group. Once 
a virtual call is assigned to a DTE/DCE interface, it is treated as a regular 
call. 


When virtual calls are placed to a hunt_group address in the case where 
Specific addresses have also been assigned to the individual DTE/DCE 
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interfaces, the CLEAR_INDICATION packet (when no CALL ACCEPTED 
packet has been transmitted) or the CALL CONNECTED packet transferred 
to the calling DTE optionally will contain the called address of the selected 
DTE/DCE interface and the Called Line Address Modified Notification 
facility (see § 6.26) indicating the reason why the called address ts dif- 
ferent from the one originally requested. 


Virtual calls may be originated by the DTEs on DTE/DCE interfaces 
belonging to the hunt group; these are handled in the normal manner. In 
particular, the calling DTE address transferred to the remote DTE in the 
INCOMING CALL packet is the hunt_group address unless the DTE/DCE 
interface has a specific address assigned. Permanent virtual circuits may 
be assigned to DTE/DCE interfaces belonging to the hunt-group. These 
permanent virtual circuits are independent of the operation of the | 

hunt group. 


some networks may 
e apply virtual call subscription time user facilities in common to all 
DTE/DCE interfaces in the hunt_group, 
e¢ place a limit on the number of DTE/DCE interfaces in the 
hunt_group, and/or 
« constrain the size of the geographic region that can be served by 
a single hunt_group. 


6.25 Call_Redirection and Call_Deftection Reiated Facilities 
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These optional user facilities apply only to virtual call service in a 
DTE/DCE environment. 


The set of Call. Redirection and Call Deflection optional user facilities 
enables the redirection or the deflection of calls destined to one DTE (the 
“originally called DTE”) to another DTE (the “alternative DTE”). The 

Call Redirection facility (see § 6.25.1) allows the DCE, in specific circum- 
stances, to redirect calls destined to the originally called DTE; no 
INCOMING CALL packet is transmitted to the originally called DTE when 
such a redirection is performed. The Call Deflection related facilities (see 
§ 6.25.2) allow the originally called DTE to deflect individual incoming calls 
after reception of the INCOMING CALL packet by this originally called 
DTE. A DTE may subscribe to the Call Redirection facility, to the 

Call Deflection Subscription facility, or to both. 


When a call to which the Call_ Redirection or Call. Deflection facilities are 
applied is cleared, the clearing cause shall be that generated during the 
last attempt to reach a called DTE/DCE interface. 


Call Redirection or Call Deflection is limited to the network of the DTE ori- 
ginally called. 


The basic service is limited to one Call Redirection or Cail Deflection. In 
addition, some networks may permit a chaining of several 
Call_Redirections or Call Deflections. In all cases, networks will ensure 
that loops are avoided and that the connection establishment phase has a 
limited duration, consistent with the DTE time limit T21 (see Table D-2). 
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When the virtual call is redirected or deflected, the CLEAR INDICATION 
packet, when no CALL ACCEPTED packet has been transmitted by any 
DTE or the CALL_CONNECTED packet transferred to the calling DTE will 
contain the called address of the alternative DTE and the 

Called Line Address Modified Notification facility (see § 6.26), indicating 
the reason why the called address is different from the one originally 
requested. . 7 


When the virtual call is redirected or deflected, some networks may indi- 
cate to the alternative DTE that the call was redirected or deflected, the 
reason for redirection or deflection, and the address of the originally 
called DTE, using the Call_ Redirection or Call_Deflection Notification 
facility (see § 6.25.3) in the INCOMING CALL packet. 


Further information on the coding of the alternative DTE address is given 
in Appendix V, “Addresses in Call Set-up and Clearing Packets.” 


6.25.1 Call_ Redirection 


Call Redirection is an optional user facility agreed upon for a period of 
time. This user facility, if subscribed to, redirects INCOMING CALL 
packets destined to this DTE when: 


« the DTE is out-of-order, 
¢ the DTE is busy, or 


Some networks may provide Call_ Redirection only in case #1. 
Some networks may offer, in addition, 

¢ systematic Call Redirection due to a prior agreement with the 
subscriber other than #1 and #2 above, agreed to between the 
network and the subscriber. 


In addition to the basic service, some networks may offer either one of the 
following (mutually exclusive) capabilities: 


¢ A list of alternate DTEs (C1, C2, ...) is stored by the network of the 
originally called DTE (DTE B). Consecutive attempts of 
Call Redirection are tried to each of these addresses, in the order 
of the list, up to the completion of the call. 


e Call Redirections may be logically chained; if DTE C has sub- 
scribed to Call Redirection to DTE D, a call redirected from DTE B 
to DTE C may be redirected to DTE D; Call _Redirections and | 
Call Deflections may also be chained. | 


The order of call set-up processing at the originally called DCE as well as 
the alternative DCE will be according to the sequence of call progress 
Signals in Table 1/CCITT Recommendation X.96. For those networks that 
provide systematic Call Redirection due to a prior request by the sub- 
scriber, the systematic Call_ Redirection request will have the highest pri- 
ority in the call set-up processing sequence at the originally called DCE. 
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> 6.25.2.1 Call Deflection Subscription 
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Call Deflection Subscription is an optional user facility agreed upon for a 
period of time. This facility, if subscribed to, enables the DTE to request, 
by using the Call Deflection Selection facility (see § 6.25.2.2), that an indi- 
vidual call presented to it by transmission of an INCOMING CALL packet 
be deflected to an alternative DTE. 


The DCE may use a network timer, with a value agreed to with the sub- 
scriber, to limit the time between the transmission to the originally called 
DTE of an INCOMING CALL packet and the request by this originally 
called DTE to deflect the call. Once this timer has expired, the originally 
called DTE will no longer be permitted to use the 

Call Deflection Selection facility to deflect the call. If the originally called 
DTE tries to deflect the call after the expiration of this internal timer, the 
network clears the call. 


6.25.2.2 Call_Deflection_Selection 


Call_ Deflection Selection is an optional user facility which may be used 
on a per virtual call basis. This facility may be requested by a DTE only if 
it has subscribed to the Call Deflection Subscription facility (see § 
6.25.2.1). 


The Call Deflection Selection facility (see §§ 7.2.1 and 7.2.2.10) may be 
used by the called DTE in the CLEAR REQUEST packet only in direct 
response to an INCOMING CALL packet to specify the alternative DTE 
address to which the call is to be deflected. If the 

Call Deflection Selection facility is used in the CLEAR _REQUEST packet, 
then the DTE must also include any CCITT-specified DTE facilities and 
user data to be sent to the alternative DTE. Up to 16 octets of user data 
may be included in the CLEAR REQUEST packet in this case, if the ori- 
ginal call was established without fast select; up to 128 octets of user data 
may be included in the CLEAR REQUEST packet if the original call was 
established with fast select. If no CCiTT-specified DTE facilities are 
included in the CLEAR REQUEST packet, then there will be none in the 
INCOMING CALL packet to the alternative DTE. If no clear user data is 
included in the CLEAR REQUEST packet, then no call user data will be 
included in the INCOMING CALL packet to the alternative DTE. When 
requested for a given virtual call, the network deflects the call to the alter- 
native DTE and does not respond to the calling DTE as a result of the 
clearing at the originally called DTE/DCE interface. The X.25 facilities that 
are present in the INCOMING CALL packet transmitted to the alternative 
DTE are those that would have been present in the INCOMING CALL 
packet if the call was a direct call from the calling DTE to the alternative 
DTE; moreover, the Call_ Redirection or Call_ Deflection Notification facility 
(see § 6.25.3) may also be present, if supported by the network. 


Note: 


For an interim period, some networks may not allow a deflected 
INCOMING CALL packet’s contents to be modified, in which case 
a deflecting DTE is not permitted to use any user data or 
CCITT-defined facilities in the CLEAR_REQUEST packet. 
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> _ The bit 7 of the General Format Identifier (see § 4.3.3) in the 
= INCOMING CALL packet transmitted to the originally called DTE or the 
> alternative DTE has the same value as the same bit in the 

> CALL REQUEST packet. 


> If the network offers only the basic service and if a Call_ Redirection or 
> Call Deflection has already been performed, the DCE clears the call as 
> indicated in Appendix C, “Packet Layer DCE Actions” when the 

> Call Deflection Selection facility is used. 


> 6.25.3 Call_Redirection_Or_Call_Deflection_Notification 


> Call Redirection Or Call Deflection Notification is a user facility used by 
> the DCE in the INCOMING CALL packet to inform the alternative DTE: 

> e« that the call has been redirected or deflected, 

> | e why the call was redirected or deflected, and 

> e the address of the originally called DTE. 

> The following reasons can be indicated with the use of the 

> Call Redirection Or Call Deflection Notification facility (see §§ 7.2.1 and 

> 7.2.2.11). 

> e Call Redirection due to originally called DTE out of order. 

> e Call Redirection due to originally called DTE busy. . 

> e Call Redirection due to prior request from the originally called 

> DTE for systematic Call_ Redirection. 

> e Call Deflection by the originally called DTE. 

> Some networks may also use the following reason in the network- 
> dependent cases not described in this specification. 

= e Call distribution within a hunt group. 


6.26 Called Line_Address Modified_Notification 


S This optional user facility applies only to virtual call service in a DTE/DCE 
S environment. 


Called Line Address Modified Notification is an optional user facility 
used by the DCE in the CALL_CONNECTED or CLEAR_INDICATION 
packets to inform the calling DTE as to why the called address in the 
packet is different from that specified in the CALL REQUEST packet. 


When more than one address applies to a DIE/DCE interface, the 

Called Line Address Modified Notification facility may be used by the 
DTE in the CLEAR REQUEST packet (when no CALL_ACCEPTED packet 
has been transmitted) or the CALL_ACCEPTED packet, when the called 
address is present in the packet and different from that specified in the 


> INCOMING_CALL packet. When this facility is received from the DTE, the 
> DCE will clear the call if the called address is not one of those applying to 
> the interface. 
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Note: 


The DTE should be aware that a modification of any part of the 
called DTE address field without notification by the 

Called Line Address Modified Notification facility may cause the 
call to be cleared. 


The following reasons can be indicated with the use of the 
Called Line Address Modified Notification facility in CALL CONNECTED 
or CLEAR_INDICATION packets transmitted to the calling DTE: 


e call distribution within a hunt_group; 
¢ call redirection due to an originally called DTE being out-of-order; 
¢ call redirection due to an originally called DTE being busy; 


e call redirection due to a prior request from the originally called 
DTE for systematic call redirection; 


e called DTE originated (more than one address applies to the 
DTE/DCE interface); 


« call deflection by the originally called DTE. 


In CALL_ ACCEPTED or CLEAR_REQUEST packets, the reason indicated in 
conjunction with the use of the Called Line Address Modified Notification 
facility should be “Called DTE originated.” 


_ When several reasons could apply to a same cail, the reason to be indi- 
cated by the network in the CALL CONNECTED or the CLEAR INDICATION 
packet by means of the Called _Line_ Address Modified Notification facility 
is as specified below: 


e The indication of a call redirection or call deflection in the network 
has precedence over the indication of distribution within a hunt 
group over a called DTE originated indication 


e The called DTE originated indication has precedence over the indi- 
cation of distribution within a hunt group 


e When several call redirection or call deflection have been per- 
formed, the first one has precedence over the others 


The called DTE address indicated in the CALL CONNECTED or the 
CLEAR_INDICATION packet should correspond to the last DTE which has 
been reached or attempted to reach.. 


6.27 Transit_Delay Selection_and_Indication 


This optional user facility applies only to virtual call service in a DTE/DCE 
environment. 


Transit_Delay_Selection_and_Indication is an optional! user facility which 
may be requested by a DTE for a given virtual call. This facility permits 
selection and indication, on a per call basis, of the transit delay applicable 
to that virtual call as defined in § 4.3.8. 
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A DTE wishing to specify a desired transit delay in the CALL REQUEST 
packet for a virtual call indicates the desired value (see §§ 7.2.1 and 
7.2.2.12). 


The network, when able to do so, should allocate resources and route the 
virtual call in a manner such that the transit delay applicable to that call 
does not exceed the desired transit delay. 


The INCOMING CALL packet transmitted to the called DTE and the 

CALL CONNECTED packet transmitted to the calling DTE will both contain 
the indication of the transit delay applicable to the virtual call. This transit 
delay may be smaller than, equal to, or greater than the desired transit 
delay requested in the CALL_REQUEST packet. 


Note: 


During the interim period when this optional user facility is not yet 
supported by all networks, the indication of the transit delay appli- 
cable to the virtual call will not be provided in the 

INCOMING CALL packet transmitted to the called DTE, if etthera 
transit network or the destination network does not support this 
facility. 


6.28 TOA/NPI Address Subscription 


TOA/NPL Address Subscription (Type of Address/Numbering Plan Identi- 
fier) is an optional user facility agreed upon for a period of time for virtual 
calls. 


When this facility is subscribed to, the DCE and the DTE will always use 
the TOA/NPI address format of the call set-up and clearing packets trans- 
mitted between the DCE and the DTE (see § 5.2.1). 


When the DCE needs to transmit an INCOMING CALL packet to a DTE 
which has not subscribed to this facility, and the calling OTE address to be 
transmitted in this packet cannot be contained in the non-TOA/NPI 
address format of the address block, the DCE will include no calling DTE 
address. 


Note: 


Some administrations may provide a subscription time option of - 
the TOA/NPI address subscription facility, allowing the user to 
indicate that the DCE shall clear the call with the cause “Incom- 
patible Destination” and a specific diagnostic in the case 
described in the last paragraph above, rather than include no 
calling DTE address. 
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ids and Registration 


The formats described in this section apply only to optional user and 
CCITT-specified DTE facilities that may be present in the call setup and 
call clearing packets used in conjunction with the virtual call service. 
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7.1 General 


The Facility field is present only when a DTE is using an optional user 
facility requiring some indication in 


CALL REQUEST, 

INCOMING CALL, 

CALL_ACCEPTED, 

CALL CONNECTED, 
CLEAR_REQUEST, 
CLEAR_INDICATION packets or 

DCE CLEAR CONFIRMATION packets. 


The Registration field is present 


e ina REGISTRATION REQUEST packet only when the DTF wishes 
to request the DCE to agree to or to stop a previous agreement for 
an optional user facility, and 


» ina REGISTRATION CONFIRMATION packet when the DCE wishes 
to indicate 


— which optional user facilities are available, or 
-- which optional user facilities are currently in effect. 


The Facility/Registration field contains one or more facility/registration 
elements. The first octet of each facility/registration element contains a 
Facility/Registration code to indicate the facility or facilities 
requested/negotiated. The remaining octets of a facility/registration 
element contain the Facility/Registration Parameter Field length, when 
present, and then the Facility/Registration Parameter Field. 


Notes: 


1. The action taken by the DTE when a facility code appears more 
than once ts to use the last one. A DTE should not repeat a 
facility code. 


2. ADTE may either ignore or treat as an error those facility codes 
that are not supported or that do not apply in a DTE/DTE environ- 
ment. If the DTE chooses to treat these situations as an error, 
then it transmits a CLEAR REQUEST packet across the interface 
with a cause indicating “DTE Originated” and the diagnostic 
“Facility Code Not Allowed.” 


The Facility/Registration codes are divided into four classes, by making 


use of bits 8 and 7 of the Facility/Registration code field, in order to 
specify Facility/Registration parameters consisting of ‘1’, ‘2’, ‘3’, or a vari- 
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able number of octets. The general class coding of the 
Facility/Registration code field is shown in Table 26. 


Table 26: General Class Coding for Facility/Registration Code Fields 


eee oe Characteristics 
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11XXXXKX*xX Variable Length Parameter Field 


For class ‘D’ the octet following the Facility/Registration code indicates the 
length, in octets, of the Facility/Registration parameter field. The 
Facility/Registration parameter field length is binary coded and bit 1 is the 
low order bit of this indicator. 


The formats for the four classes are shown in Figure 7-1. 


CLASS A | CLASS B 


Bits 8 7 6 5 4 3 2 1 Bits 8 7 6 5 4 3 2 
Octet Octet 
010 0 XK K XK xX X X 


1 | Facility/Registration Facility/Registration 
parameter field parameter 


field 


CLASS C CLASS D 


Bits 8 / 6 9 4. 3 2 1 Bits 8 7 6 5 4 3 2 1 


Octet Octet 
1 0X X X XK X X Q0O}1 1 X X X X XK X 


Facility/Registration 1 | Facility/Registration 
parameter field length 
parameter 


Facility/Registration 


field 
parameter 


field 


Figure 7-1. Facility/Registration Element - General Formats 
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The Facility/Registration code field is binary coded and, without extension, 
provides for a maximum of 64 Facility/Registration codes for classes ‘A’, 
‘B’ and ‘C’ and ‘63’ Facility/Registration codes for class ‘D’ giving a total of 
‘255’ Facility/Registration codes. 


Facility/Registration code x‘FF’ is reserved for extension of the 
Facility/Registration code. The octet following this octet indicates an 
extended Facility/Registration code having the format ‘A’, ‘B’, ‘C’ or ‘D’ as 
defined above. Repetition of Facility/Registration code x'FF’ is permitted 
and additional extensions thus result. 


The coding of the Facility/Registration parameter field is dependent on the 
facility being requested/negotiated. 


A Facility/Registration code may be assigned to identify a number of spe- 
cific facilities, each having a bit in the parameter field indicating facility 
requested/facility not requested. In this situation, the parameter field is 
binary encoded with each bit position relating to a specific facility. A ‘O’ 
indicates that the facility related to the particular bit is not requested and 
a ‘1’ indicates that the facility related to the particular bit is requested. 
Parameter bit positions not assigned to a specific facility are set to zero. 
If none of the facilities represented by the Facility/Registration code is 
requested for a virtual call or for On-Line Facility Registration; the 
Facility/Registration code and its associated parameter field need not be 
present. 


In addition to the Facility/Registration codes defined in § 7.2, other codes 
may be used for: 


— non-X.25 facilities which may be provided by some networks 
(CALL SET-UP and REGISTRATION packets); 


— CCITT-specified DTE facilities as described in Appendix | (Annex G 
of CCITT Recommendation X.25) for CALL SET-UP, 
CLEAR_REQUEST and CLEAR_INDICATION packets. 


IBM SNA DTEs may reject received packets indicating 
facility/registration codes that are unknown or not supported by 
Clearing the virtual call, resetting the permanent virtual circuit or 
Restarting the DTE/DCE interface with appropriate Cause and Diag- 
nostic codes (see Appendix H, “DTE-Generated Diagnostic Codes”). 


Facility/Registration markers, consisting of a single octet pair, are used to 
separate requests for X.25 facilities as defined in §§ 6 and 7 from other 
categories as defined above, and, when several categories of facilities are 
simultaneously present, to separate these categories from each other. 


The first octet of the marker is a Facility/Registration code field and is set 
to zero. The second octet is a Facility/Registration parameter field. 


The Facility/Registration parameter field of a marker is set to zero when 
the marker precedes requests for: 


— Registration codes specific to the local network (REGISTRATION 
packets); 
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— non-X.25 facilities provided by the network in case of intranetwork 
calls (CALL SET-UP packets); and, 


— non-X.25 facilities provided by the network to which the calling 
DTE is connected, in case of inter-network calls (CALL SET-UP 
packets). | 


The facility parameter field cf a marker is set to x'FF’ when the marker 
precedes requests for non-X.25 facilities provided by the network to which 
the called DTE is connected, in case of inter-network calls (CALL SET-UP 
packets). | 


The facility parameter field of a marker is set to x‘OF’ when the marker 
precedes request for CCITT-specified DTE facilities. 


All network(s) will support the facility marker with a facility parameter field 
set to x‘FF’ or x‘OF’. 


DTEs shall not use a facility marker with a facility parameter field set to 

x FF’ in case of intranetwork calls. However, if a DTE uses such a marker 
in an intranetwork call, the DCE is not obliged to clear the call, and the 
marker, with the corresponding facility requests, may be transmitted to 
the remote DTE. 


Facility/Registration codes for X.25 facilities and for the other categories of 
facilities may be simultaneously present. However, requests for X.25 facil- 
ities must precede the other requests, and requests for 
CClITT-specified_ DTE facilities must follow the other requests. 


The coding of CCITT-specified DTE facilities should comply with the 
description in Appendix G, “CCITT-Specified DTE Facilities.” However, the 
DCE is not required to verify that compliance. If the network verifies that 
compliance and finds an error, it may clear the call with the cause 

“Invalid Facility Request.” The CCiTT-specified DTE facilities are other- 
wise passed unchanged by public data networks between the two packet- 
mode DTEs. 


7.2 Coding of Facility Field in Call Set-up and Clearing 


The coding of the Facility Code field and the format of the 
Facility Parameter field are the same in the various Call Set-up and 
Clearing packets in which they are used. 


7.2.1 Coding of the Facility Code Fields 
Table 27 gives the coding of the Facility Code fields and the packet types 
in which they may be present. 
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Table 27: Coding of the Facility Code Field 


Packet | | | Facility Code 
‘ Type 'CRQ, INC) CAK| CCN; CLR Bit 
Facility ; - 87654321, 
(ees : en oe 


Flow Control Parameter Negotiation 
~ Packet Size 
~ Window Size 


0010| 
0011 


| 0100 1 
| 0100 1 
{ 
| 


{ 
| 
| 
Closed User Group Selection | X | X 
~ Basic Format | 
- Extended Format | 
}— : ; : 


| 
CUG with Outgoing Access Selection | X | X | 
{ 


- Basic Format | | 00001001 
~ Extended Format | | 01001000: 


L a 


| Bilateral Closed CUG Selection 


pon —- ee 


Reverse Charging 


Fast Select 


NUI Selection 


Charging Information 
- requesting service 
— receiving information 

. monetary unit 
. segment count 
- call duration 

RPOA Selection 
— Basic Format 
- Extended Format 


Call Deflection Selection | | 11010001 
| 


Call Redirection or Deflection 
Notification 


gE 223 oe 


Called Line Address Nodified 
Notification 


Transit Delay Selection and Indication 


Marker (see § 7.1) 


Reserved for Extension 
*1: This facility code and associated facility parameter will be present in the 
INCOMING CALL packet if either or both of 
REVERSE_CHARGING (if REVERSE_CHARGING ACCEPTANCE is subscribed to or 
FAST SELECT (if FAST SELECT ACCEPTANCE is subscribed to) is indicated. 
They may, but need not necessarily, be present if neither 
REVERSE_CHARGING ACCEPTANCE nor 
FAST_SELECT_ACCEPTANCE are subscribed to. 
*2: This facility code and associated facility parameter may be present in 
CALL_ACCEPTED packet only in conjunction with the NUI_ Subscription 
facility (see § 6.21.3). 
*3: Only when the reason "Called DTE Originated" is used in the parameter 
field (see §§ 6.26 and 7.2.2.12). 
*4: The DIE is not allowed to use both Call Deflection Selection and Called Line_ 
Address Modified Notification facilities in the same CLEAR_REQUEST packet. 
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7.2.2 Coding of the Facility Parameter Fields 


7.2.2.1 Flow_Control_Parameter_Negotiation Facility 


Packet Size 


The packet size for the direction of transmission from the called 
DTE is indicated in bits 4, 3, 2 and 1 of the first octet of the 

Facility Parameter field. The packet size for the direction of trans- 
mission from the calling DTE is indicated in bits 4, 3, 2 and 1 of the 
second octet. Bits 8, 7, 6 and 5 of each octet must be zero. 


The four bits indicating each packet size are binary coded and 
express the logarithm base 2 of the number of octets of the 
maximum packet size. 


Networks may offer values from 4 to 12, corresponding to packet 
sizes of 16, 32, 64, 128, 256, 512, 1024, 2048 or 4096, or a contig- 
uous subset of these values. All Administrations will provide a 
packet size of ‘128’ octets. 


Window Size 


The window size for the direction of transmission from the called 
DTE is indicated in bits 7 through 1 of the first octet of the 
Facility. Parameter field. The window size for the direction of 
transmission from the calling DTE is indicated in bits 7 through 1 
of the second octet. Bit 8 of each octet must be zero. 


The bits indicating each window size are binary coded and 
express the size of the window. A value of zero is not allowed. 


Window sizes of 8 to 127 are only valid if extended sequence num- 
bering is used (see § 6.2). The ranges of contiguous values 
allowed by a network with normal numbering and extended num- 
bering are network dependent. All Administrations will provide a 
window size of ‘2’. | 


7.2.2.2 Throughput Class Negotiation Facility 
The throughput class for the direction of data transmission from the called 
DTE is indicated in. bits 8, 7, 6 and 5. The throughput class for the direc- 
tion of data transmission from the calling DTE is indicated in bits 4, 3, 2 


and 1. 


The four bits indicating each throughput class are binary coded and corre- 
spond to the throughput classes indicated in Table 28. 
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7.2.2.3 Closed User _Group_Selection Facility 


Basic Format 


The index to the closed user group selected for the virtual call is 
in the form of two decimal digits. Each digit is coded in a semi- 

octet in binary coded decimal with bit 5 being the low order bit of 
the first digit and bit 1 being the low order bit of the second digit. 


Indexes to the same closed user group at different DTE/DCE inter- 
faces may be different. 


Extended Format 


The index to the closed user group selected for the virtual call ts 
in the form of four decimal digits. Each digit is coded in a semi- 
octet in binary coded decimal with bit 5 of the first octet being the 
low order bit of the first digit, bit 1 of the first octet being the low 
order bit of the second digit, bit 5 of the second octet being the 
low order bit of the third digit and bit 1 of the second octet being 
the low order bit of the fourth digit. 


Indexes to the same closed user group at different DTE/DCE inter- 
faces may be different. 
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7.2.2.4 Closed_User_Group_with_Outgoing_Access_Selection Facility 


° Basic Format 


The index to the closed user group selected for the virtual call is 
in the form of two decimal digits. Each digit is coded in a semi- 

octet in binary coded decimal with bit 5 being the low order bit of 
the first digit and bit 1 being the low order bit of the second digit. 


Indexes to the same closed user group at different DTE/DCE inter- 
faces may be different. 


Extended Format 


The index to the closed user group selected for the virtual call is 
in the form of four decimal digits. Each digit is coded in a semi- 
octet in binary coded decimal with bit 5 of the first octet being the 
low order bit of the first digit, bit 1 of the first octet being the low 
order bit of the second digit, bit 5 of the second octet being the 
low order bit of the third digit and bit 1 of the second octet being 
the low order bit of the fourth digit. 


Indexes to the same closed user group at different DTE/DCE inter- 
faces may be different. 


7.2.2.5 Bilateral_Closed_User_Group_ Selection Facility 
The Bilateral Closed User Group facility and, thus, the 
Bilateral_ Closed User _Group_ Selection facility is not used in SNA envi- 
ronments. | | 


?.2.2.6 Reverse Charging and Fast_Select Facilities 
The coding of the facility parameter field is: 


Bit 1 = O for Reverse Charging not requested 


1 for Reverse Charging requested 


Bit 8 = O, and 
Bit 7 = Oor 1 for Fast Select not requested (see Note 2) 
Bit 8 = 1, and | 


Bit 7 = 0 for Fast_Select requested with no restriction on 
response 


1 for Fast_Select requested with restriction on response 


Notes: 


2 
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Bits 6, 5, 4, 3, and 2 may be assigned to other facilities in the 
future; presently, they are set to ‘0’. 


. Ina CALL_REQUEST packet, a DTE shall set bit 8 equal to 0 and 


bit 7 equal to O for Fast Select not requested. In an INCOMING 
CALL packet, however, a DTE shall interpret bit 8 set to 0 and bit 7 
set to 0 or 1 as Fast_Select not requested. 


> 7.2.2.f NUI Selection Facility 

The octet following the Facility. Code field indicates the length, in octets, of 
> the Facility. Parameter field. The following octets contain the network user 
> identifier, in a format determined by the network Administration. 


7.2.2.8 Charging_Information Facility 
e Parameter Field for Requesting Service 


The coding of the Facility. Parameter field is: 


Bit 1 = O for Charging Information not requested 
1 for Charging Information requested 


Note: 
Bits 8, 7, 6, 5, 4, 3, and 2 may be assigned to other 
facilities in the future; presently, they are set to 0. 
« Parameter Field Indicating Monetary. Unit 


The octet following the Facility Code field indicates the length, in 
octets, of the Facility. Parameter field. 


+ The parameter field indicates the charging. The coding of the 
= parameter remains a subject for further study by the CCITT. 


e Parameter Field Indicating Seqment Count 


The octet following the Facility Code field indicates the length, in 
octets, of the Facility. Parameter field and has the value n x 8 
where ‘n’ is the number of different tariff periods managed by the 


S network. The Facility Parameter Field follows the length and indi- 
S cates the segment count for each tariff period. 

S Each segment count is represented in the Facility Parameter Field 
S by eight octets. For each tariff period, the first four octets of the 


Facility Parameter field indicate the number of segments sent to 
the DTE. The following four octets indicates the number of seg- 
ments received from the DTE. 


Each digit is coded in a semi-octet in binary coded decimal and bit 
1 or bit 5 of each semi-octet is the low order bit of each digit and 
bits 4 through 1 of the last octet represent the lowest order digit of 
the segment count. | 


Segment size and the specific packet types to be counted are a 
matter of the Administration in the case of national calls and are 
specified in CCITT Recommendation D.12 for international calls. 


Note: 


The relationship between a particular tariff period 
and its place in the parameter field is a national 
matter. The order is given by each Administration. 


« Parameter Field Indicating Call Duration 


The octet following the Facility Code field indicates the length, in 

octets, of the Facility Parameter field and has the value n x 4 

where ‘n’ is the number of different tariff periods managed by the 
S network. The Facility Parameter Field follows the length and indi- 
S cates the call duration for each tariff period. 
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S Each call duration is represented in the Facility Parameter Field by 

S four octets. For each tariff period, the first octet of the 
Facility Parameter field indicates number of days, the second indi- 
cates number of hours, the third indicates number of minutes and 
the fourth indicates number of seconds. Each digit is coded in a 
semi-octet in binary coded decimal and bit 1 or bit 5 of each semi- 
octet is the low order bit of each digit. Bits 4 through 1 of each 
octet represent the low order digit. 


Note: 


The relationship between a particular tariff period 
and its place in the parameter field is a national 
matter. The order is given by each Administration. 


1.2.2.9 RPOA_Selection Facility 


« Basic Format 


The parameter field contains the data network identification code 
for the requested initial RPOA transit networ and is in the form of. 
four decimal digits. 


Each digit is coded in a semi-octet in binary coded decimal with 
bit 5 of the first octet being the low order bit of the first digit, bit 1 
of the first octet being the low order bit of the second digit, bit 5 of 
the second octet being the low order bit of the third digit and bit 1 
of the second octet being the low order bit of the fourth digit. 


Serene nate tet ne RA mente At ere ee 


The octet following the Facility Code field indicates the length, in 
octets, of the Facility Parameter field and has the value n x 2, 


S when ‘n’ is the number of RPOA transit networks selected. The 
S Facility Parameter Field follows the length and indicates the data 
S network identification code for each RPOA transit network. 


Each RPOA transit network is indicated by a data network identifi- 
cation code, and is in the form of four decimal digits. Each digit is 
coded in a semi-octet in binary coded decimal with bit 5 of the first 
octet being the low order bit of the first digit, bit 1 of the first octet 
being the low order bit of the second digit, bit 5 of the second 
octet being the low order bit of the third digit and bit 1 of the 
second octet being the low order bit of the fourth digit. 


RPOA transit networks should appear in the Facility. Parameter 
field in the order that the calling DTE wishes them to be traversed. 


>7.2.2.10 Call_Deflection_Selection Facility 


= The octet following the facility code indicates the length, in octets, of the facility 
= parameter field and has the value n + 2, where n is the number of octets nec- 
> essary to hold the called address of the DTE to which the call is to be deflected 
> (the alternative DTE). 

> The first octet of the facility parameter field indicates the reason for the DTE 
So deflecting the call. The coding of this octet is as follows. 
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Coding of Call Deflection Reason Field 


bits 
a J &  S.4. 22 Reason 


Call deflection by the originally called DTE. 
Call deflection by gateway as a result of call 
redirection due to originally called DTE busy. 

Call deflection by gateway as a result of call 
redirection due to originally called DTE out of order. 
Call deflection by a gateway as a result of call 
redirection due to prior request from originally 

| called DIE for systematic call redirection. (Note a) 


Note a) Applies where the originally called DTE is on a private network and 
the call redirection is to a DIE address on the public network that 
presented the incoming call to the private network. 


ANN ANNAN A ANA NA AARAA ANA KH AHA MN 


The second octet indicates the number .of semi-octets in the alternate DTE 
address. This address length indicator is binary coded and bit 1 is the low 
order bit. Its value is limited to 15 when the A bit is set to 0 (see § 5.2.1), to 17 
when the A bit is set to 1. 


VVV Vv 


The following octets contain the alternative DTE address, using coding which 
corresponds to the coding of the called DTE address field in the address block 
(see § 5.2.1). When the number of semi-octets of the alternative DTE address is 
odd, a semi-octet with zeros in bits 4, 3, 2 and 1 will be inserted after the last 
semi-octet in order to maintain octet alignment. 


VVVVV 


> 7.2.2.11 Call Redirection or Call_Deflection_Notification Facility 
The octet following the Facility _Code field indicates the length, in octets, of the 
Facility Parameter field and has the value n + 2, where ‘n’ is the number of 


S octets necessary to hold the originally called DIE address. The Facility Param- 
S eter Field follows the length and indicates the reason for the redirection as well 
S as the originally-called DTE address. 


The first octet of the Facility Parameter field indicates the reason for the 
> Call Redirection or Call Deflection and has one of the following values. 
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VV 
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Coding of Call Deflection or Call Redirection Reason Field 


bits 
So fF 70. & <4 ae 2 Reason 


Originally called DTE busy 

Call distribution within a hunt group (Note a) 
Originally called DIE out-of-order 

Systematic call redirection 

Call deflection by a the originally called DTE (Note b) 
Call deflection by gateway as a result of call redirec— 


tion due to originally called DTE busy (Notes b & c) 
Call deflection by gateway as a result of call redirec—| 
tion due to originally called DTE out-of-order (b & c) 
Call deflection by gateway as a result of call redirec— 
tion due to prior request from originally called DIE 
for systematic call redirection (Notes b & c) 


Note a) This value may be used by some networks for network-dependent reasons 
not described in this architecture. | 

Note b) These codes are those set by the DTE in the Call Deflection Selection 
faci lity (See §7.2.2.10) 

Note c) Applies where the originally called DTE is on a private network and the 
call redirection is to a DTE address on the public network that presented the 
incoming call to the private network. 


The second octet indicates the number of semi-octets in the originally called 
DTE address. This address length indicator is binary coded and bit 1 is the low 
order bit. Its value is limited to 15 when the A bit is set to 0 (see § 5.2.1), to 17 
when the A bit is set to 1. 


The following octets contain the originally called DTE address. When both the 
calling DTE and the alternative DTE have subscribed to the TOA/NPI address 
subscription facility (see § 6.28), or when none of them have subscribed to this 
facility, the originally called DTE address is coded identically to the called DTE 
address field in the CALL REQUEST packet. When these conditions are not sat- 
isfied, the network converts from one address format to the other (see § 3.2.1). 
When the number of semi-octets of the originally DTE address is odd, a semi- 
octet with zeros in bits 4, 3, 2 and 1 will be inserted after the last semi-octet in 
order to maintain octet alignment. 


?.2.2.12 Called _Line_Address Modified_Notification Facility 


The coding of the Facility Parameter field for 
Called_Line Address Modified Notification is as follows. 
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Coding of Facility Parameter Field for Called Line Address Modified Notification 


Reason 


Call redirection due to called DTE busy (Note a) 
Call distribution within a hunt group (Note a) 
Call redirection due to called DTE out-of-order (Note a) 
Call redirection due to prior DTE request for 
systematic call redirection | (Note a) 
Call deflection by a the originally called DIE 
Call deflection by gateway as a result of call redirec— 
tion due to originally called DTE busy (Notes b & c) 
Call deflection by gateway as a result of call redirec— 
tion due to originally called DTE out-of-order (b & c) 
Call deflection by gateway as a result of cal] redirec— 
| tion due to prior request from originally called DIE 
for systematic call redirection © (Notes b & c) 


Note a) The bit indicated as "X" set to 0 indicates that the called line address 
modification occurred in a public data network and set to 1 indicates it 
occurred in a public data network. 

Note b) These codes are those set by the DTE in the Call Deflection Selection 
Tacphity “(see-§ 7. 2ee.. 10): 


Notele ee lee: wpeve race Gras yea led on a private network an 


call redirection is to a DTE address on the public network that presente 
incoming call to the private network. | 


rm 
«ad 


NAA DAN MA NMNAMNANANnHNAMNMNA NHN NA NN NANH KH HAR VH HA KHRHRUNA HUH MH 
Oo. rd 
cr 
pe 
@ 


S Note: 
S Bit 8, when received from the called DTE and when it is not set to ‘1’, is 
S forced to ‘1’ by the DTE. 


7.2.2.13 Transit_Delay_Selection_and_Indication Facility 


> This parameter is two octets. Transit delay is expressed in milliseconds, binary 
> coded, with bit 8 of octet 1 being the high order bit and bit 1 of the octet 2 being 
> the low order bit. The expressed transit delay mzy have a value from 0 to 

> 65534 (all bits set to 1 but the low order bit). 

> Note: 

> During the interim period when this optional user facility is not yet sup- 

> ported by all networks, the transit delay indicated in the 

> CALL CONNECTED packet transmitted to the calling DTE should have a 

= value of 65535 (all ones) when either a transit network involved. in the 

> virtual call or the destination network does not support this facility. So, 

> this value should be interpreted by the calling DTE as an indication that 

> the actual transit delay cannot be transmitted to it. 
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7.3 Coding of the Registration Field of Registration Packets 


The coding of the Registration Code field and the format of the 
Registration Parameter field are the same in REGISTRATION REQUEST and 
REGISTRATION CONFIRMED packets in which they are used. 


7.3.1 Coding of the Registration Code Fields | 
Table 29 gives the coding of the Registration Code fields and the packet types 
in which they may be present. 


Table 29: Coding of the Registration Code Field 


Facility 


Facilities that may be negotiated only 
when all logical channels use for vir- 
tual calls are in state pl 


Registration 
Code Bits 
8765 4321 


May be Used 
in 


Availability of facilities 01060 0110 
0000 011490 


Note: It is for further study whether or not the Call Redirection | 
facility may be negotiated. 


The absence of a Registration Code in the REGISTRATION REQUEST packet 
means that the DTE does not want to modify the previous agreement for the 
concerned facility(ies). 


The absence of a Registration Code in a REGISTRATION CONFIRMATION 
packet means that the concerned facility(ies) is not supported by the DCE or is 
not permitted by the DCE to be negotiated by the On-Line Facility_Registration 
facility. 


DTEs and DCEs should discard Registration Elements with Registration _Codes 
that they do not support or do not know. 
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7.3.2 Coding of Registration Parameter Fields 


7.3.2.1 Restricted Negotiable Facilities 


(Facilities that may be negotiated only when all Logical Channels used for 
Virtual Calls are in State p‘). 


Each one of the following bits of the Registration Parameter field corresponds 
to one facility that may be negotiated only when all logical channels for virtual 
calls are in state p1 (see Appendix F, “On-Line Registration Facility 
Applicability”) and that needs only a single bit value to indicate its value. The 
correspondence between bits and facilities is given below. 


Bit 8 } 
Bit 
Bit 
Bit 


/ 
6 Reserved for future use (see Note 1) 
5 

Bit 6 
3: 
2 
] 


Bit 
Bit 
Bit 


D-Bit Modification facility 
Packet Retransmission facility 
Extended Packet Sequence Numbering facility (see Note 2) 


Notes: 


1. Bits 8, 7, 6, 5 and 4 should be ignored when received and set to ‘0’ 
when transmitted by the DTE or DCE. 


2. The exact method for negotiation of this facility is the subject of further 
study by the CCITT. 


A bit set to ‘1/0’ in a REGISTRATION REQUEST packet means that the DTE asks 
for the DCE to invoke/revoke the corresponding facility. 


A bit set to ‘1/0’ in a REGISTRATION CONFIRMATION packet means that the 
corresponding facility is invoked/revoked by the DCE. 


7.3.2.2 Unrestricted Negotiable Facilities 


Each one of the following bits of the Registration Parameter field corresponds 
to one facility that may be negotiated at any time (see Appendix F, “On-Line 
Registration Facility Applicability’). The correspondence between bits and facil- 
ities is given below. 
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> Octet 


Reserved for future use (see Note) 


1 
> Bit 8: 
Bit 7: Charging Information facility (per interface basis) 
Bit 6: Throughput Class Negotiation facility 
Bit 5: Flow Control Parameter Negotiation facility 
Bit 4: Reverse Charging Acceptance facility 
Bit 3: Fast Select Acceptance facility 
Bit 2: Outgoing Calls Barred facility 
Bit 1: Incoming Calls Barred facility 
> Octet 2 
> Bit. 02 - } 
> Bit 7: } 
> Bit 6: 3 
> Bit 5: } Reserved for future use (see Note) 
> Bit 4: } | 
> Bit 32 + 
> Bit 2: } 
> Bit 1: } 


Note: 
Bit 8 of octet 1 and all bits of octet 2 should be ignored when received 
and set to ‘0’ when transmitted by the DTE or DTE. 


A bit set to ‘1/0’ in a REGISTRATION REQUEST packet means that the DTE asks 
for the DCE to invoke/revoke the corresponding facility. 


A bit set to ‘1/0’ in a REGISTRATION CONFIRMATION packet means that the 
corresponding facility is invoked/revoked by the DCE. 


7.3.2.3 Availability of Facilities — 
Each one of the following bits of the Registration Parameter field corresponds 


o to one facility whose availability must be indicated to the DTE. The correspond- 
> ence between bits and facilities is given below. | 
> Octet 1 
> Bit 8: Reverse Charging facility (see Note 1) 
> Bit 7: Reverse Charging Acceptance facility 
> Bit 6: Charging Information facility (per call basis) (see Note 1) 
> Bit 5: Charging Information facility (per interface basis) 
>> Bit 4: Called Line Address Modified Notification facility (see Note 1) 
Bit 3: D-Bit Modification facility | 
Bit 2: Packet Retransmission facility 
Bit 1: Extended Packet Sequence Numbering facility 
Octet 2 
> Bit 8: } 
> Bit 7: } Reserved for future use (see Note 2) 
> Bit 6: 
| Bit 5: RPOA Selection (per call basis) (see Note 1) 
Bit 4: Logical Channel Types Ranges registration facility 
Bit 3: Non-Standard Default Packet Sizes registration facility 
Bit 2: Non-Standard Default Window Sizes registration facility 
Bit 1: 


Default Throughput Classes Assignment registration facility 
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Notes: 


1. A bit set to ‘1/0’ for a corresponding facility indicates that it is 
available/not-available for use by the DTE; no further negotiation is 
required for these facilities. 


2. Bits 8, 7 and 6 of octet 2 should be ignored when received and set to ‘0’ 
when transmitted. 


A bit set to ‘1/0’ by the DCE in a REGISTRATION CONFIRMATION packet means 
that the corresponding facility is available/not-available for use by the DTE or is 
available/not-available to be negotiated by the DTE. 


7.3.2.4 Non-Negotiable Facilities Values 
Each one of the following bits of the Registration Parameter field corresponds 
to one facility which is not available for negotiation but whose value should be 
indicated to the DTE. 


Bit 1: Local Charging Prevention facility 
Note: 


Bits 8, 7, 6, 5, 4, 3 and 2 should be ignored when received and set to ‘0’ 
when transmitted. 


A bit is set to ‘1/0’ in a REGISTRATION CONFIRMATION packet when the DCE 
has invoked/revoked the corresponding facility. 


7.3.2.5 Default Throughput Classes Assignment 
The throughput class for the direction of data transmission from the DTE issuing 
the REGISTRATION REQUEST packet is indicated in bits 8, 7,6 and 5. The 
throughput class for the direction of data transmission to the DTE issuing the 
REGISTRATION packet is indicated in bits 4, 3, 2 and 1. | 


The four bits indicating each throughput class are binary coded and correspond 
to throughput classes as indicated in Table 28 (see § 7.2.2.2). 


Note: 


Registration applies only to facility values for virtual calls; it does not 
apply to facility values for permanent virtual circuits. 


7.3.2.6 Non-Standard Default Packet Sizes 
The packet size for the direction of data transmission to the DTE tssuing the 
REGISTRATION REQUEST packet is indicated in bits 4, 3, 2 and 1 of the first 
octet. The packet size for the direction of data transmission from the DTE 
issuing the REGISTRATION REQUEST packet is indicated in bits 4, 3, 2 and 1 of 
the second octet. Bits 8, 7, 6 and 5 of each octet must be zero. 


The four bits indicating each packet size are binary coded and express the log- 
arithm base 2 of the number of octets of the maximum packet size. 


Networks may offer values from 4 to 12, corresponding to packet sizes of 16, 32, 


64, 128, 256, 512, 1024, 2048 and 4096, or a subset of these values. All Adminis- 
trations will provide a packet size of ‘128’ octets. 
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Note: 


Registration applies only to facility values for virtual calls; it does not 
apply te facility values for permanent virtual circuits. 


7.3.2. Non-Standard_Default_Window_Sizes 
The window size for the direction of data transmission to the DTE issuing the 
REGISTRATION REQUEST packet is indicated in bits 7 to 1 of the first octet. 
The window size for the direction of data transmission from the DTE issuing the 
REGISTRATION REQUEST packet is indicated in bits 7 to 1 of the second octet. 
Bit 8 of each octet must be zero. 


The bits indicating each window size are binary coded and express ne size of 
the window. A value of zero is not allowed. 


Window sizes of 8 to 12/7 are only valid when extended sequence numbering is 
used. The range of values allowed by a network are network dependent. All 
Administrations will provide a window size of ‘2’. 


Note: 


Registration applies only to facility values for virtual calls; it does not 
apply to facility values for permanent virtual circuits. 


7.3.2.8 Logical Channel Types Ranges 
The octet following the Registration Code field indicates the length, in octets, of 
the Registration Parameter field and shall indicate 14 octets. The Registration 
Parameter Field then consists of the following 14 octets. 


Bits 4, 3, 2 and 1 of octets 1, 3, 5, 7, 9 and 11 of the Registration Parameter field 
shall contain the logical channel group number for parameters LIC, HIC, LTC, 
HTC, LOC and HOC, respectively, (see Appendix A, “Logical Channel Ranges”). 
Bits 8, 7,6 and 5 of these octets must be set to zero. 


Octets 2, 4, 6, 8, 10 and 12 of the Registration Parameter field shall contain the | 
logical channel numbers for parameters LIC, HIC, LTC, HTC, LOC and HOC, 
respectively, (see Appendix A, “Logical Channel Ranges’). 


No one-way incoming logical channels is represented by LIC and HIC both 
equal to zero; no two-way logical channels is represented by LTC and HTC both 
equal to zero; and, no one-way outgoing logical channels is represented by 
LOC and HOC both equal to zero. 


Bits 4, 3, 2 and 1 of octet 13 of the Registration Parameter field shall contain 
the high order bits of the total number of logical channels to be used for virtual 
calls. Bits 8, 7, 6 and 5 of octet 13 must be set to zero. Octet 14 of the 
Registration Parameter field shall contain the low order bits of the total number 
of logical channels to be used for virtual calls. 


Notes: 


1. The inequalities of Appendix A, “Logical Channel Ranges” must apply 
to non-zero values of LIC, HIC, LTC, HTC, LOC and HTC. 


2. The total number of logical channels to be used for virtual calls as indi- 
cated in octets 13 and 14 is equal to the sum of the number of one-way 
incoming logical channels, two-way logical channels and one-way out- 
going logical channels. 
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Chapter 8. Logical Link Control SNA-to-SNA 
Connections 


In SNA-to-SNA environments virtual circuits are viewed by the higher layers as 
communication lines (physical media) with tne ability to support multiple ses- 
sions. Permanent virtual circuits (PVCs) appear to the higher layers of SNA as 
dedicated (leased) lines, while virtual calls (VCs), often referred to as switched 
virtual circuits (SVCs), appear as switched (dial-up) lines. 


In this environment a Logical Link Control (LLC) function is required to accom- 
modate SNA adjacent node physical services equivalent to such SDLC functions 
as: 


e identification information exchange (XID); 

¢ operational mode selection (SNRM, SABM, etc.); 
e jink test (TEST); and, 

e link disconnection (DISC); 


as well as to enhance the quality of the underlying service exhibited in 
some environments. 


Differences in the error detection and recovery characteristics of adjacent SNA 
nodes in Public Switched Telephone Network and Packet-Switched Data 
Network environments are shown in Figure 8-1 on page 8-3. 


8.1. Introduction 
Three types of logical link control are defined: 


1. BNN (Boundary Network Node) - Qualified Logical Link Control (QLLC) 
which employs the Qualified Data Indicator ‘Q-bit’ in X.25 DATA packets 
to identify unnumbered and supervisory (Receive Ready) QLLC com- 
mands and responses. QLLC, described in Appendix O, “Description of 
the BNN_ Qualified Logical Link Control - (QLLC) Procedures” on 
page O-1, is designed for use with PSDN virtual circuit services that 
exhibit quality of service characteristics that are acceptable to the user; 


2. Physical Services Header (PSH) LLC whica is employed in certain early 
IBM SNA X.25 DTE implementations and described briefly in 
Appendix J, “Physical Services Headers” on page J-1; and, 


3. Enhanced Logical Link Control (ELLC) which employs extended HDLC 
formats and the procedures described in Appendix M, “Description of 
the Enhanced Logical Link Control - (ELLC) Procedures” on page M-1. 
ELLC provides error detection and optional retransmission recovery 
capabilities designed to enhance the quality exhibited by underlying 
virtual circuit services. While ELLC may be selected by the user ona 
virtual circuit basis, the optional retransmission capability applies to the 
DTE/DCE Interface and may be controlled by the value of LLC param- 
eter LN2 (see “Maximum Number of LPDU Transmissions - (LN2)” on 
page M-24). 


QLLC procedures described in Appendix O, “Description of the BNN Qualified 
Logical Link Control - (QLLC) Procedures” on page O-1 are considered ‘base 
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architecture’ for all IBM SNA X.25 DTEs except the IBM-5973 Network Interface 
Adapter (NIA) which supports only the PSH protocol. The optional ELLC proce- 
dures described in Appendix M, “Description of the Enhanced Logical Link 
Control - (ELLC) Procedures” on page M-1 may be supported by IBM SNA X.25 
DTEs in environments where virtual circuit quality of service characteristics 
need to be enhanced to satisfy SNA user requirements. Consequently, IBM 
SNA X.25 DTEs that remotely attach to the IBM 5973 NIA must be capable of 
using PSH_LLC, as well as QLLC and, optionally, ELLC. 


A Protocol_identifier (Pl) carried in the first octet of the Call_User_Data (CUD) 
field in X.25 CALL_REQUEST packets is used to select the LLC protocol and 
Cause Code set (normal or extended) applicable for operation on SVCs. 

CALL REQUEST packets for virtual calls desiring to use ELLC procedures have 
P| = x'C6’ (or x‘CE’ for extended Cause Codes). DTEs that do not support 
ELLC, and IBM 5973s that support only PSH_LLC, reject such calls by sending a 
CLEAR_REQUEST packet with the ‘DTE-Originated’ cause code and the diag- 
nostic code #12, ‘Invalid LLC Type’. Calling DTES may then reinitiate the call by 
sending a CALL REQUEST packet with Pl = x'C3' {or x°CB’ for extended Cause 
Codes) requesting a connection for QLLC operation, or with Pl = x‘C2’ to 
request a connection for PSH_LLC operation. 


The LLC protocol used for operation on PVCs is established by bilateral agree- 
ment between communicating DTEs. 
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Figure 8-2 on page 8-4 shows the correlation between ELLC/QLLC functions 


and equivalent SDLC functions. 


EEG QLLC SDLC 
Function|Function| Function 


LSABHE 


| worse QDISC  orsc PSDISC 


LXID QXID pxmD PSXID 
LTEST QTEST test PSTEST 


| PSCONTACT 


PSH LLC |Primary| Secondary 
Function jCommand| Response 


DATA X 


PSCONTACT X 


aa 


X 


Boge 


X 


X 


PSDISC 


LRR 


LRNR 


LREJ 


LPDUR FRMR 


Note: PSH LLC is primary/secondary only. ELLC is peer-to-peer only. 
TBD -— To Be Determined. | 


“OF mUR 


- 


Figure 8-2. COMMAND/RESPONSE REPERTOIRE for ELLC versus QLLC versus SDLC 
and PSH_LLC | | 


8.1.1 Call User Data (CUD) Field Format 
The format of the CUD field for CALL REQUEST and INCOMING CALL packets 
on SNA-to-SNA connections is illustrated in Figure 8-3 on page 8-5. 


8.1.1.1 Protocol Identifier (Pl) : 
The Pl is mandatory and occupies the first octet of the CUD. It is used to distin- 
guish between SNA-to-SNA connection and SNA-to-non_SNA connections as 
well as to select the LLC protocol to be used on SNA-to-SNA connections as 
described “Introduction” on page 8-1. 


8.1.1.2 Field _Format_Identifier (FFI) 
The FFI is optional and, when present, defines the format of the remainder of 
the CUD field. IBM SNA X.25 DTE implementations that use FFls must make 
such use optional. IBM SNA X.25 DTEs that do not support FFIs must accept 
and ignore CUD fields of up to 15 octets in addition to the Protocol Identifier. 
Figure 8-4 on page 8-6 illustrates the format of the CUD field for the only 
optional FFI currently defined, b‘xxxxxxx1’ where the bits denoted by ’x’s, bits 8 
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+ thru 2, are reserved and set to zeroes. The FFI should not be present as the 


+++tet¢¢4¢44 


+ last byte of the CUD, i. e., if there is no Call Control Indicator. 
Bits 8 / 6 5 4 3 2 i 
Octet 
Q Protocol Identifier 
X DCI 
(Optional) 
1 Field Format Identifier. (FFI) 
ELLC Call Control Indicator 
2 Xx X x x 
3 : 
- | Format Specific Field | | 
15 
= Not Applicable (irrelevant). 
= 'Q' for initial connection. 
'1' for connection recovery. 
= 'Q' for Standard DTE Diagnostic Codes and the 
DTE-Generated Cause Code x'Q0' (See Appendix H) 
for SNA Specific Diagnostic Codes and the 
a DTE-Generated Cause Code x'80' for 1984/1988 X.25 
+ for SNA Specific Diagnostic Codes and the 
= DTE-Generated Cause Code x'80' for 1980 X.25 


Note: Bits indicated as 'x' are reserved and should be set to 0's 


Figure 8-3. CALL_USER_DATA Field Format for CALL_REQUEST and INCOMING CALL 
Packets on SNA-to-SNA Connections 


8.1.1.3 ELLC_Call_Control_Indicator - (ELLC_CCl) 
The ELLC CCl (bit 1 of octet 2) is used to distinguish between initial connection 
requests and connection recovery requests, while the remaining bits, denoted 
by ‘x’s in Figure 8-3 and Figure 8-4 on page 8-6, are reserved and set to zero 
(O's). 


8.1.1.4 Connection_Identifier - (CID) 
The CID is eight octets in length and permits IBM SNA X.25 DTEs to accept or 
reject incoming calls based on its content. The following rules apply to the use 
of the optional CID: 


ie Some. IBM SNA X.25 DTEs may not support the Connection_Identifier. 
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++t+4+4+4+44 


+++ 


8-6 


2. For IBM SNA X.25 DTEs that do support a Connection Identifier, its use 
is optional on a per call basis at the discretion of the user. 


3. IBM SNA X.25 DTEs that support Connection Identifiers may reject 
incoming calls by transferring a CLEAR REQUEST with the appropriate 
diagnostic code when the Connection Identifier does not compare with 
one that is expected. 


Bits 8 


Octet 
0 


i 
oO 


Note: Bits 


Protocol Identifier 
x DCI 


Field Format Identifier 
x X X X 


ELLC Call Control Indicator 
X X x X 


Reserved 


Connection Identifier 


Applicable (irrelevant). 

for initial connection. 

for connection recovery. 

for Standard Diagnostic Codes and the 
DTE-Generated Cause Code x'00' (See Appendix H) 
for SNA Specific Diagnostic Codes and the 
DTE-Generated Cause Code x'80' for 1984/1988 X.25 
for SNA Specific Diagnostic Codes and the 


DTE-Generated Cause Code x'8Q' for 1980 X.25 


indicated as 'x' are reserved and should be set to 0's 


Figure 8-4. CUD Field Format for CALL_REQUEST and INCOMING CALL Packets with 
Connection_Identifiers : 
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9.1 Virtual Circuit Parameter Considerations 


Some system parameters that apply to the entire X.25 DTE/DCE interface or to 
particular portions of the interface and are agreed upon for a period of time 
with the network Administration. Others that apply only to virtual calls are 
established during call establishment. 


9.1.1 Parameters Applicable to the Entire Interface 


9.1.1.1 Non-Standard Default Window Size 
Values other than ‘2’ can be agreed upon with some network Administrations. 
This parameter has local significance and must be handled directly by the DTE. 
It will impact the amount of buffer used in the DTE. 


9.1.1.2 Incoming Calls Barred 
No parameter is needed at the DTE. The SNA control point should not enable 
the links (ports) to receive incoming calls. 


9.1.1.3 Outgoing Calls Barred 
No parameter is needed at the DTE. Its user should not issue calls. Calls will 
be cleared by the network and reporting to the control point or operator will be 
performed. 


9.1.1.4 Single Closed User Group 
No parameter is required at the DTE. Calls issued to a DTE outside of the CUG 
are cleared by the network. DTEs report the contents of Clearing Cause and 
Diagnostic Code fields to the SNA control point or to the local operator. 


9.1.1.5 Incoming Calls Barred within a Single CUG 
This is a combination of §§ 9.1.1.2 and 9.1.1.4. 


9.1.1.6 Outgoing calls Barred with a Single CUG 
This is a combination of §§ 9.1.1.3 and 9.1.1.4. 


9.1.1.7 Multiple Closed User Groups 
For support on incoming calls only, a parameter setting is needed in the DTE to 
permit handling of the indication in the facility field. For outgoing calls, the DTE 
needs a mechanism to select the desired CUG. 


9.1.1.8 Reverse Charging Acceptance 
The DTE must be informed that the facility has been subscribed to because the 
facility field in the INCOMING CALL packet will indicate Reverse Charging when 
a calling DTE has requested it. 


A clever DTE should be able to detect reverse charged calls coming from 
callers that should not reverse charge to it. This is not feasible in NCP for lack 
of available inbound reporting at connection establishment time between NCP 
and SSCP. | 
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9.1.1.9 Local Address 
DTEs that use the calling DTE address field in CALL REQUEST packets must 
Store their address locally for this purpose. 


9.1.2 Parameters Applicable to Portions of the Interface 


9.1.2.1 Number and Type of Virtual Circuits 
All DTES must support logical channel 0 as the path for RESTART and DIAG- 
NOSTIC packets. 


single logical channel DTEs must use logical channel number ‘1’ for data 
transfer, whether this single channel is supporting a PVC or a VC. The number 
and type (PVC or VC) of virtual circuits must be agreed upon with the network 
Administration for each DTE/DCE interface. 


9.1.2.2 Non-Standard Default Packet Size | 
Maximum packet lengths of ‘16’, ‘32’, ‘64’, (all-networks offer 128°), ‘256°, ‘512’ 
or 1024 octets can be subscribed to when the netwcrk offers the corresponding 
facility. A single value applies for all logical channels assigned for Virtual Call 
service. An individual value can be selected for each PVC logical channel. 
These parameters are required at the DTE and must be in agreement with the 
network Administration. 


When the network does not allow default value selection, only ‘128’ applies, 
unless the negotiation facility is used for VCs. Note that in this case, only ‘128’ 
can apply to PVCs. 


9.1.2.3 One-way Logical Channel Incoming 
No parameter is required at the DTE. Call requests are cleared by the network 
and DTEs report the contents of the Clearing Cause and Diagnostic Code fields 
to the SNA control point or to the local operator. 


9.1.2.4 One-way Logical Channel Outgoing 
The DTE must Know which channels are reserved. In addition, a per call 
parameter is required to flag each call request received from the control point 
or the operator in order to authorize the DTE to choose one of the reserved 
channels. 


9.1.3 Parameters Applicable per Call 
These parameters must be given to the X.25 DTE/DCE interface handler at each 
call. They are not necessarily reflected on the interface. In the case of NCP, 
these parameters must be transmitted from the SSCP to NCP. In the present 
state of the architecture, the dial digit field of the SNA ‘connect out’ function can 
be used for this purpose. 


Further architecture work is required to specify appropriate formats and proce- 
dures for this facility. Clearly, such a mechanism only permits selection of the 
facility as a function of the SNA node to be dialed - not as a function of the 
individual session requirements when the virtual circuit is shared among 
several sessions. 
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9.1.3.1 Selection of One-way Logical Channel Outgoing 


This permits a call to be made using one of the channels reserved for outgoing 
only. Refer to § 9.1.2.4. 


9.1.3.2 Packet Size Selection 


If the nature of the applications requiring use of the VC is known, a specific 
parameter should indicate the requested packet size.. If it is not known, the DTE 
Should always initialize the negotiation with the maximum packet size it can 
Support. The result of the negotiation need not be reported back to the oper- 
ator or control point. 


9.1.3.3 Throughput Class Negotiation 


9.2 Security 


Because of potential cost-of-service reductions, multiple virtual circuit DTE’s 
Should implement Throughput Class Negotiation. 


9.2.1 SNA-to-SNA Connections 


Called DTEs can implement a rudimentary calling DTE identification check by 
testing the calling DTE address in INCOMING CALL packets. DTEs can elect to 
implement as a user option the connection identifier capability defined for CALL 
REQUEST and INCOMING CALL packets. See “Connection Identifier - (CID).” 


Care must be exercised in choosing cryptographic techniques. Data link control 
level cryptographic products defined for SNA products are not defined for the 
X.25 link and packet levels and cannot be used. Cryptographic products 

defined for SNA above, and transparent to, the data link control level can be 
used. 


9.2.2 SNA-to-non SNA Connections 


Security techniques are specific to the particular non-SNA remote DTE being 
supported. In general, techniques used for SNA-to-SNA connections are not 
applicable. 


9.3 Reliability, Availability and Serviceability (RAS) 


9.3.1 Philosophy 


RAS characteristics of PSDNs are not clearly established. However, numerous 
error detection and reporting mechanisms are included throughout this inter- 
face specification to aid in problem determination. 


The fundamental philosophy adopted for error reporting in PSDN environments 
is one of commonality. IBM SNA X.25 DTEs cover a broad spectrum of RAS 
capabilities. Therefore, reporting to a higher layer may mean different things 
for different products. These can range from simply reporting an error condi- 
tion to the local operator of a simple DTE to full compatibility with Network 
Problem Determination and Analysis programs. 


A common set of Diagnostic Codes is specified in Appendix H, “DTE-Generated 


Diagnostic Codes” for use by all IBM SNA X.25 DTEs in reporting error condi- 
tions and abnormal situations to higher layers of SNA. 
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9.3.2 Summary of Error Conditions 
Detectable error conditions are divided into four general categories: 


1. those resulting from receipt of unsupported packet types (i.e., 
DCE_INTERRUPT packets); 


2. those that can result from a discrepancy between the DTE and DCE 
interpretations of the state of some subscribed interface parameter (i.e., 
receipt of an INCOMING CALL packet on a logical channel assigned for 
permanent virtual circuit service); 


3. those most likely resulting from a malfunction of the DCE (i.e., receipt of 
an unsolicited DCE RESTART CONFIRMATION packet); and 


4. those caused by failures at the physical layer or the data link layer (i.e., 
dropping of the Data Set Ready indication). 


IBM SNA X.25 DTEs, upon detection of errors in category: 


‘1’ or ‘2’ - clear the virtual call or reset the permanent virtual circuit if such 
an action is permitted without violating any procedure. The error condition 
is reported to a higher layer of SNA; the received packet is discarded. 


3 transmit a RESTART REQUEST packet across the DTE/DCE interface, 
place all virtual circuits in an inoperative state and report the error condi- 
tion to the higher layers of SNA. 


‘4’ - perform the LAPB Link_Resetting procedure and report the event to a 
higher layer of SNA. 


9.3.3 General Recommended Actions 
All errors detected at the X.25 DTE/DCE interface, either by IBM SNA X.25 DTEs 
or their associated DCEs, that result in CLEAR, RESET or RESTART indications 
must be reported to the SNA control point or to the local operator, as appro- 
priate. The Call Progress Signals (CPS) defined in CCITT Recommendation 
X.96 used for ‘Network Generated’ Cause and Diagnostic Codes defined in 
CCITT Recommendation X.25 and a common set of ‘DTE-Originated’ diagnostic 
codes defined in Appendix H, “DTE-Generated Diagnostic Codes” for IBM SNA 
X.25 DTEs to aid in problem determination are used for reporting purposes. 
Session outage notifications are propagated in accordance with general SNA 
mechanisms, using INOPERATIVE (INOP) to the control point and RECORD FOR- 
MATTED MAINTENANCE STATISTICS (RECFMS) or RECORD MAINTENANCE 
STATISTICS (RECMS) to Communication Network Management (CNM). 


Further architectural definition is required to specify formats and procedures 
needed for: | 
¢ |Inoperative (INOP) notifications generated by IBM SNA X.25 DTEs. 


¢ Record Formatted Maintenance Statistics (RECFMSs) or Record Mainte- 
nance Statistics (RECMSs) generated by IBM SNA X.25 DTEs. 


e Other network problem determination and analysis procedures. 
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9.4 Relationship to ISO_Open System Interconnection (OSI) 


9.4.1 Protocol Identification 
+ ISO DTR 9577, “Proposal for a New Work Item: Protocol Identification in the 
Network Layer,” is envisioned as producing a Type 3 Technical Report to 
record the structure and values of Protocol Identifiers for the OSI Network 
Layer. 


Two distinct protocol identifiers are currently proposed: 


1. An Initial Protocol Identifier - (IPI) used to identify the first protocol oper- 
ating directly above the Data Link Layer; and, 


¢ contained in the first octet of protocol control information (e.g., the 
first octet (octet 1’) of X.25 packets), 
e structured as depicted in Figure 9-1 on page 9-6, and 
« decomposed according to the following procedure: 
a. if the value of IPI is non-zero, and dits 6 & 5 of the PD octet are 
binary zero, then: 
— bits 8 & 7 are examined to determine the administrative 
authority responsible for defining bits 4, 3, 2 & 1. 
b. if bits 6 & 5 have any value other than zero, then: 
— the remaining bits are interpreted according to the proce- 
dures defined in ISO-8208. 
co. if the-value- of the PO is zero. the 
— [I$0-8473 Inactive Subset is identified. 


2. A Subsequent Protocol Identifier - (SPI) used to identify the protocol 
operating over the first protocol. 


* contained in the first octet of Protocol Service Data carried by the 
initial protocol (e.g., octet ‘0’ of CUD in X.25 Call Set-Up packets), 
e structured as depicted in Figure 9-2 on page 9-/, and 
e decomposed according to the following procedure: 
a. if the value of the SPI is non-zero, then: 
— bits 8 & 7 are examined to determine the administrative 
authority (if any) responsible for defining bits 6...1. 
b. bits 6 through 1 are then examined to ascertain the particular 
protocol identified by the SPI octet. : 
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+++ 


Allocation Category 
Protocol 


Bit Pattern 
8765 432 


Allocation by CCITT 
IS0-8473 Inactive Subset 
CCITT 1.70 Teletex Network (CSPDN Operation) 


Reserved 


CCITT 1.451/Q.931 (ISDN) 


} Reserved 


Allocation by ISO 
— Reserved 
TS0-84/73 Connectionless Protocol | 
IS0-8473 ES-to-IS Routing (Provisional) 


} Reserved 


Reserved for Extension by N-5166 


1100 xxx x | Not Constrained by N-5166 


ISQ-8208/CCITT X.25 — Modulo 8 
[S0-8208/CCITT X.25 — Modulo 128 
[S0-8208/CCITT X.25 — GFI Extension 


OPT. SES HE 
xx l0 xxXxxXx 
eM FE 


Figure 9-1. ISO/IEC TC_97/SC_6 N-5166 IPI Structure and Values 
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Bit Pattern Allocation Category 
8765 4321 Protocol 


00xx xxx x | Allocation by CCITT 
O'@> -0::0'-0:-0 IS0-8473 Inactive Subset 
0001 CCITT X.29 
0010 CCITT 1.70 Teletex Transport 
0011 


oe be et } TSO-8073 DAD1 and CCITT X.244 
OD 2b, He ek 


Allocation by National Bodies 


10x x xX x x x | Allocation by ISO 
OO. 000-6 — Reserved 
oc Came TS0-8473 Connectionless Protocol 
0010] ISO DIS 9542 (Provisional) 
0011 ISO DIS 9068 (Provisional) 
0) 1-0-9 TS0-8878 Annex A (X.25 SNDCP) 
OT Od 
oh } Reserved 
Lo: 2°): 21 
Td" “Qu Oe 
11 eh ; Not Constrained by N-5166 
i ae Se a es 


11141 =#1314141 +41 Reserved for Extension by N-5166 


Figure 9-2. ISO/IEC TC_97/SC_6 N-5166 SPI Structure and Values 


SNA-Specific use of the first octet of the CUD field in X.25 Call Set-Up 
packets conforming to CCITT and ISO Protocol Identification is depicted in 
Figure 9-3 on page 9-8 and Figure 9-4 on page 9-8. 
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SNA/X.25 Protocol Identifier — (CUD Octet 0) 
Protocol 


Bit Pattern | 
87 65 4321 


SNA-Speci fic 
SNA-to-non_SNA- 
SNA-to-SNA, PSH, x'00' 
SNA-to-SNA, QLLC, x'00' 
SNA-to-SNA, ELLC, x'00' 
SNA-Specific PI Extension, x'QQ' 
— Reserved 
SNA-to-SNA, QLLC, x'80O!' 
SNA-to-SNA, ELLC, x'80' 
SNA-Specific PI Extension, x'8Q' 


fs 
-— 
>] 
© 
x< 


OrPrPrPrO@®Ooe x 

Ore OdQOrevwr OQ xk x 
> ll cel cee eee eee cee oe oe > 4 
Oorordrcdcr® x x 


| — Reserved 


© 
isa 
age 
© 


© 
— 
oe 
}— 


SNA-Specific PI Extension, x'QQ' 


po 
© 
<p) 


— Reserved 


SNA-Specific PI Extension, x'Q0' 


od 18 

ded. ed SNA-Specific PI Extension, x'80' 
x x 0x SNA-to-non_ SNA 

0010 — Reserved 

0011 — Reserved 

0110 — Reserved 

0111 

1010 


— Reserved 


SNA~Specific PI Extension, x'80! 


— Reserved 


SNA-Specific PI Extension, x'80' 


Unassigned values are reserved — SNA-to-non SNA 


Figure 9-3. SNA-Specific Protocol Identifier Values 


Bit Pattern SNA/X.25 Protocol Identifier Extension 
8765 4321 (CUD octet 3) 


} Reserved 


— Reserved for SNA~specific Extension 


Figure 9-4. SNA-Specific Extended Protocol Identifier Values 
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9.4.2 Priority 


support of Open System Interconnection (OSI) requires that the 
CCITT Specified DTE Facility Priority Facility (see “Priority Facility” on 
page G-7/) be supported. 
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Appendixes 


Appendixes. 


Architecture Reference 


Appendix A. Channel Ranges 


Logical channel number one (1) is used by IBM SNA X.25 DTEs that support a 
Single logical channel. 


For each multiple logical channel DTE/DCE interface, a range of logical chan- 
nels will be agreed upon with the Administration according to Figure A-1. 


Reserved for Interface Control 


Permanent Virtual Circuits 


One-Way 
Incoming 


LTC 
: Two-way Virtual Calls 
Hic | 
LOC 
; One-Way 
a ox Outgoing 
HOC 


: Non-Assigned 
4095 


LCI = Logical Channel Identifier 
LIC = Lowest Incoming Channel 
HIC = Highest Incoming Channel 
LTC = Lowest Two-Way Channel 

HTC = Highest Two-Way Channel 
LOC = Lowest Outgoing Channel 
HOC = Highest Outgoing Channel 


Figure A-1. Logical Channel Assignments 


Logical channel ‘0’ is reserved exclusively for the transmission of RESTART, 
DIAGNOSTIC, and REGISTRATION packets. 
LCI: 


= 1 to LIC-1 is the range of logical channels assigned for permanent virtual 
circuits. 


= LIC to HIC is the range of logical channels which are assigned to 
one-way incoming logical channels for virtual calls (see “One-Way Logical 
Channel Incoming”). 
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= LTC to HTC is the range of logical channels which are assigned to 
two-way logical channels for virtual calls. | 


= LOC to HOC is the range of logical channels which are assigned to 
one-way outgoing logical channels for virtual calls (see “One-Way Logical 
Channel Outgoing”). 


= HIC + 1to LTC -1, HTC + 1to LOC - 1, and HOC +1 to 4095 are non- 
assigned logical channels. 


With reference to Figure A-1 on page A-1: 


Notes: 


1. 
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The reference to the number of logical channels is made according to a 
set of contiguous numbers from 0 (lowest) to 4095 (highest) using 12 bits 
made up of the 4 bits of the Logical Channel Group Number (see §-5.1.2) 
and the 8 bits of the Logical Channel Number (see §-5.1.3). The num- 
bering is binary coded using bit positions 4 through 1 of octet one fol- 
lowed by bit positions 8 through 1 of octet two with bit 1 of octet two 
being the low order bit. 


. All logical channel! boundaries are agreed upon with the Administration 


for a period of time. 


. To avoid frequent rearrangement of logical channels, not all logical 


channels within the range allocated for permanent virtual circuits are 
necessarily assigned. 


. In the absence of permanent virtual circuits, logical channel 1 is avail- 


able for LIC. In the absence of permanent virtual circuits and one-way 
incoming logical channels, logical channel 1 is available for LTC. In the 
absence of permanent virtual circuits, one-way incoming logical chan- 
nels and two-way logical channels, logical channel 1 is available for 
LOC. 


. The DCE search algorithm for a logical channel for a new incoming call 


will be to use the lowest logical channel in the Ready state in the range 
LIC to HIC and LTC to HTC. 


. In order to minimize the risk of call collision, the DTE search algorithm 


is suggested to start with the highest numbered logical channel in the 
READY state. The DTE could start with the two-way logical channel or 
one-way outgoing logical channel ranges. 
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B.1 Symbol definition of the state diagram 


Transition 


DTE 
or Responsibility for the transition 
DEE 


State name 


PACKET TYPE Packet transmitted 


Transition 


With reference to the symbol definition: 
Notes: | 


1. States are represented by boxes wherein the state name and number 
are indicated. 


2. State transitions are represented by lines with arrows. The station (DTE 
or DCE) responsible for the transition and the packet transferred (if any) 
is indicated in the transition lines. 


B.2 Order Definition of the State Diagrams 


For the sake of clarity, the normal procedure at the interface is described in a 
number of small state diagrams. In order to describe the normal procedure 
fully, tt is necessary to allocate a priority to the different figures and to relate a 
higher order diagram with a lower one. This is done by the following means: 


— The figures are arranged in order of priority with Figure B-1 on 
page B-2 (Restart) having the highest priority and subsequent figures 
having lower priority. Priority means that when a packet belonging to a 
higher order diagram is transferred, that diagram is applicable and the 
lower order one is not. 


— The relation with a state in a lower order diagram is given by including 
that state inside a box in the higher order diagram. 
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PACKET LAYER READY 


READY 


DTE pl or dl | DCE 
(Note 1) | | 


RESTART REQUEST RESTART INDICATION 


DCE_RESTART CONFIRMATION DTE RESTART CONFIRMATION 
or or 
> RESTART INDICATION RESTART REQUEST (Note 3) 


DCE 


- DTE RESTART REQUEST 
RESTART REQUEST 


+ (Note 4) 


RESTART INDICATION 


(Note 2) 


Figure B-1. Diagram of States for the Transfer of RESTART Packets 


With reference to Figure B-1: 
Notes: | 
1. State p1 is for virtual calls and state d1 is for permanent virtual circuits. 


2. This transition may take place after time-out T10. 


> 3. This transition also takes place after timeout T10 expires the second 
> time without transmission of any packet except, possibly, a diagnostic 
> packet. 


4. This transition may take place after a 200 second time-out. 


oF 9. In a DTE/DTE environment, DCE in this diagram will be replaced by DTE. 
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CALL REQUEST INCOMING CALL 


CALL_REQUEST 


(Note 1) DTE 


DCE WAITING 


DTE WAITING 


INCOMING CALL CALL_REQUEST 


CALL COLLISION 


CALL_ CONNECTED CALL_ ACCEPTED 


DCE 


CALL_ CONNECTED 


d] 
FLOW CONTROL READY 


Ce ee 


p4 
DATA TRANSFER 


Figure B-2. Diagram of States for the Transfer of Call Set-Up Packets within the Packet Level Ready State 


Notes: 


1. This transition may take place after a 200 second time-out. 


2. In a DTE/DTE environment, DCE in this diagram will be replaced by DTE. 
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B-3 


~ CALL_CONNECTED 
(Note 1) 
or 
+ INCOMING CALL 
(Note 5) 


ANY STATE 


: DTE except 
| p6 or p/ 


CLEAR_REQUEST 


CLEAR_INDICATION 


DCE DTE | | DCE DTE 
7 CLEAR_INDICATION : CALL_ACCEPTED 
‘(Note 3) (Note 2) 
-~-------- CLEAR REQUEST | ~--------- or 
DTE CLEAR REQUEST (Note 7) DCE CLEAR INDICATION] CALL REQUEST 
(Note 4) 


DCE CLEAR CONFIRMATION | | DTE_CLEAR_CONFIRMATION 
or or | 
DCE CLEAR INDICATION CLEAR REQUEST (Note 6) 


Figure 8-3. Diagram of States for the Transfer of Call Clearing Packets | 


- With reference to Figure B-3: 
Notes: 


1. This transition is possible only if the previous state was DTE Waiting 
(p2). 

2. This transition is possible only if the previous state was DCE Waiting 
(p3). | 

3. This transition takes place after Time-out T13 expires the first time. 


- 4. This transition is possible only if the previous state was Ready (p1) or 
DCE Waiting (p3). 


5. This transition is possible only if the previous state was Ready (p1) or 
DTE Waiting (p2). 


6. This transition takes place after timeout T13 expires the second time 
without transmission of any packet except, possibly a diagnostic packet. 


7. This transition may take place after a 200 second time-out. 


8. In a DTE/DTE environment, DCE in this diagram will be replaced by DTE. 
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+ + 


DTE DCE 


FLOW CONTROL READY 


RESET INDICATION RESET REQUEST 
RESET REQUEST or or RESET INDICATION 
DCE RESET CONFIRMATION DTE_ RESET CONFIRMATION 
(Note 4) 


DCE DTE 


DTE RESET REQEUST 


DTE 


RESET REQUEST RESET INDICATION — 
(Note 2) | (Note 1) 


Figure B-4. Diagram of States for the Transfer of Reset packets in Data Transfer (p4) State 


With reference to Figure B-4: 
Notes: 
1. This transition takes place after time-out T12 expires the first time. 
2. This transition may take place after a 200 second time-out. 
3. In a DTE/DTE environment, DCE in this diagram will be replaced by DTE. 
4 


. For permanent virtual circuits, DCE enters the d1 state and may issue a 
DIAGNOSTIC packet (#51) after timer T12 expires the second time. — 
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Actions taken by the DCE on Receipt of Packets in a given State of the Packet 
Layer DTE/DCE Interface as perceived by the DCE. 


C.1 Introduction 


This appendix specifies the actions taken by the DCE on receipt of packets in a 
given state of the packet layer DTE/DCE interface as perceived by the DCE. It is 
presented as a succession of chained tables. The following rules are valid for 
all these tables: 


There may be more than one error associated with a packet. The 
network will stop normal processing of a packet when an error is 
encountered. Thus only one diagnostic code is associated with an error 
indication by the DCE. The order of packet decoding and checking on 
networks is not standardized. 


For those networks which are octet aligned, the detection of a non- 
integral number of octets may be made at the data link or packet layer. 
In this appendix, only those networks which are octet aligned and detect 
the non-integral number of octets at the packet layer are concerned 
with the considerations about octet alignment. 


In each table, the actions taken by the DCE are indicated in the fol- 
lowing way: 


— DISCARD: the DCE discards the received packet and takes no sub- 
sequent action as a direct result of receiving that packet; the DCE 
remains in the same state. 


— DIAG #x: the DCE discards the received packet and, for networks 
that implement the diagnostic packet, transmits to the DTE a DIAG- 
NOSTIC packet containing the diagnostic code #x. The state of the 
interface is not changed. 


— NORMAL or ERROR: the corresponding action is specified after 
each table. 


Appendix E, “Network Generated Diagnostic Codes” gives a list of the 
Diagnostic_Codes which may be used. 
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C.2 DCE State/Action Tables 


Table C 1: Special Cases 


Packet from the DTE Any State 


Any packet with packet length shorter than 2 octets. 
Including link layer valid I-frame containing no packet. DIAG #38 


Any packet with invalid General Format Identifier (GFI) DIAG #40 
Any packet with unassigned logical channel DIAG #36 


See Table 
C 2 


Any packet with correct GFI and assigned logical channel, 
or with correct GFI and LCI = x'0Q0' 
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VV VVVVVVVVVVVVV VV VV VV V V 


VVVVVVVVVVVVV VV 


Table C 2: Actions taken by the DCE on Receipt of Packets in a Given 
State of the Packet Layer DTE/DCE Interface as Perceived 
by the DCE: RESTART and REGISTRATION Procedures 


State of the interface 
as perceived by 
the DCE 


DTE DCE 
RESTART RESTART 
REQUEST | INDICATION 

r2 r3 


PACKET 
LAYER 
READY 

ri 


Packet Received 
from the DTE 


NORMAL ; DISCARD NORMAL 
(72) (r1) 


RESTART REQUEST 
with LCI = x'000' 


NORMAL 
ted) 


ERROR ERROR 
(r3) (r3) 


DTE_RESTART_CONFIRMATION 
with LCI = x'@00' 


# 17 
REGISTRATION REQUEST (when supported | NORMAL | NORMAL NORMAL 
by the DCE) with LCI = x'000' (r1) (r2) (r3) 


Packet supported by the DCE other DIAG 

than RESTART REQUEST, DTE RESTART # 36 

CONFIRMATION and REGISTRATION REQUEST 

(when supported by the DCE) with 

LCI = x'000' 

Packet having a Packet Type DIAG ERROR DISCARD 
Identifier which is shorter than 1 | # 38 (r3) 

octet with LCI = x'Q00' #38 


DIAG ERROR DISCARD 
# 33 (r3) 


#33 


Packet having a Packet Type 
Identifier which is undefined or not 
supported by the DCE (i.e., REJECT 
or REGISTRATION) with LCI = x'eo0' 


DISCARD 


DATA, [INTERRUPT], CALL SET-UP and 
CLEARING, FLOW CONTROL 

or RESET with assigned logical 
channel 


DISCARD 


RESTART REQUEST, DTE RESTART CONFIRM— 
ATION or REGISTRATION REQUEST (when 
supported by the network) with. 

LCI not = x'Q00' 


Packet having a Packet Type DISCARD 
Identifier which is shorter than 1 


octet with assigned logical channel 


DISCARD 


Packet having a Packet Type 
Identifier which is undefined or not 
supported by the DCE (i.e., REJECT 
or REGISTRATION packet) with 
assigned logical channel 
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With reference to Table C 2: 


Note: 


Table C_3 for logical channels assigned to virtual calls, Table C_4 for 
logical channels assigned to permanent virtual circuits. 


ERROR (r3), #x: 


The DCE discards the received packet, indicates a restarting by transmitting 
to the DTE a RESTART_INDICATION packet, with the Cause 

“Local Procedure Error” and the Diagnostic #x, and enters state r3. If con- 
nected through a virtual call, (all) distant DTE(s) are also informed of the 
restarting by a CLEAR_INDICATION packet, with the Cause 

“Remote Procedure Error” (same Diagnostic). In the case of a permanent 
virtual circuit, (all) distant DTE(s) will be informed by a RESET INDICATION 
packet, with the Cause “Remote_Procedure Error” (same Diagnostic). 


NORMAL (ri): 
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Provided none of the following error conditions have occurred, the action 
taken by the DCE follows the procedure defined in §§ 3 and 6.1, and the 
DTE/DCE interface enters state ri: 


If a RESTART REQUEST packet or DTE_ RESTART CONFIRMATION 
packet received in state r3, or a REGISTRATION REQUEST packet 
received in state r2 or r3, exceeds the maximum permitted length, is 
too short or is not octet aligned (see rule 2 in the introduction of this 
appendix), the DCE will invoke the ERROR #39, #38 or #82 proce- 
dure, respectively. 


Note: In the case of a REGISTRATION REQUEST packet received in 
state r2 or r3 with the error(s) as noted above, alternative behavior 
by the DCE its for further study. | 


Some networks may invoke the ERROR #81 procedure if the 
restarting cause field is not “DTE Originated” in the 
RESTART REQUEST packet received in state r3. 


Ifa RESTART REQUEST or a REGISTRATION REQUEST packet 
received in state r1 exceeds the maximum permitted length, is too 
short or is not octet aligned (see rule 2 in the introduction to this 
appendix), the DCE shall invoke the DIAG #39, #38 or #82 proce- 
dure, respectively. 


Some networks may invoke the DIAG #81 procedure if the restarting 
cause field is not “DTE Originated” in the RESTART REQUEST 
packet received in state r1. 


Ifa REGISTRATION REQUEST packet is received from the DTE when 
the On-Line Facility Registration facility is supported by the DCE 
but not subscribed by the DTE, the DCE shall transmit to the DTE a 
REGISTRATION CONFIRMATION packet with the Cause 

“Local Procedure Error,” the Diagnostic #42, and no Registration 
field. 


If a REGISTRATION REQUEST packet modifying one or more of the facilities 
which can take effect only when all logical channels used for virtual calls 
are in state p1 (Appendix F, “On-Line Registration Facility Applicability”) is 
received when it is possible to make modification, the DCE shall transmit a 
RESTART_INDICATION packet with the Cause 

“Registration/Cancellation Confirmed” and Diagnostic #0 and enter state 
r3, if there Is one or more logical channel assigned to permanent virtual 
circuits. This action ensures that the permanent virtual circuits are reset so 
that all of the negotiated facilities can properly take effect. 
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Table C3: Actions taken by the DCE on Receipt of Packets in a Given 


State of the Packet Layer DTE/DCE Interface as Perceived by 
the DCE: CALL SET-UP and CLEARING on Logical Channels 
Assigned to Virtual Call (see Note 1) 


) | PACKET LAYER READY rl 


Interface 
States 

Perceived 
by the DCE 


Packet on 
assigned 
LCI 


CRQ NORMAL | ERROR | ERROR DISCARD 
(p5) (p7) (p7) (p7) 
#23 | «#24 
CAC ERROR | ERROR | NORMAL | ERROR | ERROR DISCARD 
(p7) (p7) | (p4) (p7) (p7) (p7) 
#20 #21 #23 #24 
CLR NORMAL] NORMAL! NORMAL | NORMAL | NORMAL | DISCARD | NORMAL 
(p6) (p6) (p6) (p6) | (p6) (p6) (pl) 
TCC ERROR | ERROR | ERROR | ERROR ERROR | ERROR. | NORMAL 
(p7) | (p7) (p7) | (p7) (p7) (p7) (pl) 
#20 #21 #22 #23 #24 #25 I. 


DIR|FC | ERROR | ERROR | ERROR See ERROR | ERROR DISCARD 
(p7) (p7) (p7) Table (p7) (p7) (p7) 
| #20 #21 #22 C4 #24 #25 
IRR,TIR | ERROR | ERROR | ERROR See ERROR | ERROR DISCARD 
or RGR (p7) (p7) (p7) Table (p7) (p7) (p7) 
w/LCI40 | #41 #41 #41 C4 #41 #41 
UNK ERROR | ERROR | ERROR See ERROR | ERROR DISCARD 
(p7) (p7) (p7) Table (p7) (p7) (p7) 
#38 #38 #38 C4 #38 #3¢ ° 
ERROR | ERROR | ERROR See ERROR | ERROR DISCARD 
(p7) (p7) (p7) Table (p7) (p7) (p7) 
#33 #33 #33 C4 #33 #33 


CALL_REQUEST CAC: CALL ACCEPTED CLR: CLEAR REQUEST 
: DTE_CLEAR CONFIRMATION § DIR|FC: DATA, INTERRUPT, RESET or 
RGR: REGISTARTION REQUEST Flow Control 


IRR|TIR: RESTART REQUEST or DTE_RESTART CONFIRMATION 

UNK: Packet having a PTI shorter than one octet 

NUP: Packet having a PTI which is Undefined or Not Supported by the DCE 
LCI: Logical Channel Identifier 
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With reference to Table C 3: 


Notes: 


fle 


On permanent virtual circuits, only state p4 exists and the DCE takes no 
action except those specified in Table C_ 4. 


. This state does not exist in the case of an outgoing one-way logical channel 


(as perceived by the DTE). 


. This state does not exist in the case of an incoming one-way logical 


channel (as perceived by the DTE). 


ERROR (p7), #x: 


The DCE discards the received packet, indicates a clearing by transmitting 
to the DTE a CLEAR_INDICATION packet, with the Cause | 

“Local _ Procedure Error” and the Diagnostic #x, and enters state p7. If con- 
nected through a virtual call, the remote DTE is informed of the clearing by 
a CLEAR_INDICATION packet, with the Cause “Remote_Procedure_ Error” 
(same diagnostic). < 


NORMAL (pi): 


Provided none of the following error conditions have occurred, the action 
taken by the DCE follows the procedures defined in § 4 and the DTE/DCE 
interface enters state pi. In all the cases specified under, the DCE will 


transmit to the DTE a CLEAR INDICATION with the appropriate Cause and 


Diagnostic, and enter state p7. If connected through a virtual call, the 
distant DTE is also informed of the clearing by a CLEAR_INDICATION packet 
with the Cause “Remote_Procedure Error” (same Diagnostic). 
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A) CALL REQUEST packet — Specific 


| a‘ aaa | Diagnostic 

Error Condition 
3 #38 
6 
#68 
#6 


[rr nr te per ror | 


Note 1: Possible reasons for invalid address include: 
— Prefix digit not supported, 
— Invalid type of address/numbering plan identification informations (A bit set to 0) 
— National address smaller than national address format permits, 
— National address larger than national address format permits, 

DNIC less than four digits, etc. . 


8. Value of the facility length field greater than 109 Local Procedure Error 
9. No combination of facilities could equal facility length | Local Procedure Error 


Invalid Facility Req. 
Invalid Facility Req. 
13. Class coding of the facility corresponding to a length 


Local Procedure Error 
of parameter larger than remainder of packet 


Local Procedure Error 


10. Facility length larger than remainder of packet Local Procedure Error 


ll. Facility Code not allowed 


12. Facility value not allowed or invalid 


14. Facility code repeated Local Procedure Error 
Invalid Facility Req. 


Local Procedure Error 


15. Invalid network user identification 


16. NUI Selection facility expected by the DCE and not 
provided by the DTE 


17. Invalid/unsupported NUI value or missing NUI detected Access Barred 


at inter-network interface 


18. RPOA Selection required 
provided by the DTE 


RPOA Out_Of_ Order 
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| A) CALL REQUEST Packet (Continued) Specific 


Ce er eee Ee eee Diagnostic 
19. Facility value conflict sete: g., combination not supported | Invalid Facility Req. 


Invalid Facility Req. 


20. CCITT-specified DTE facility code or parameter 
not allowed or invalid 


aH 


#39 


Call User Data larger than 16 octets Local Procedure Error 


(or 128 octets for Fast-Select) 


If the virtual call cannot be established by the network, the DCE should use a Call Progress 


Signal and Diagnostic Code among the following: 


22. Requested RPOA Out_Of Order 


23. Requested RPOA invalid or not supported #119 


24. Unknown number 


| 25. Incoming call barred 


| 26. Closed user group protection 


27. Ship absent ahap: Absent 


|; 26. Reverse Charging rejected | Reverse Charging_ 
| Acceptance not 
subscribed 


Fast Select Acceptance 
not subscribed 


| 30. Called DTE out-of-order | Out-of-Order #0|>127 
| 31. No logical channel available | Number Busy 
| 32. Call collision Number Busy 


Incompatible Destina— 
| tion 


| 29. Fast Select rejected 


te tH: te 
[<>] ce (<>) 


th 
~~ 
pd 
~ 
NO 


|} 33. The remote DTE/DCE interface or the transit network does 
not support a function or a facility requested 


ee 


Note: Precise definition of error condition 30 necessitates further study and should take into 
account the possible non~-support of the virtual call service (only permanent virtual circuit) 
by the destination DTE. 


| Remote Procedure Error] (see b and 
c) below & 
Appendix D 


34. Procedure error at the remote DTE/DCE interface 


#0, 122 
or >127 


| 35. Temporary network congestion or fault condition within 
the network 


| Network_Congestion 
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| B) CALL ACCEPTED Packet - ; Specific 
Diagnostic 

1. Packet not octet aligned 
3. Address contains a non-BCD digit | 
4. Invalid calling DTE Address (see Note 1 inte A) 
5. Invalid called DTE Address (see Note 1 under A) | 
6. Value of the facility length field greater than 109 
7. No combination of facilities caus equal facility length 
8. Facility length larger than er of packet | Local Procedure Error | #38 | 
Pnetarenioe | ae 


10. Facility Value not allowed or invalid 


Class coding of the facility corresponding to a length Local Procedure Error 


of parameter field larger than remainder of packet 


Local Procedure Error io 
Invalid network user identification Invalid Facility Req. | ee 


#66 
#73 
: #84 
| 14. NUI Selection facility expected by the DCE Local Procedure Error #84 
and not provided by the DTE | | 

15. Invalid/unsupported NUI value or missing NUI detected Access barred #84 

| at inter-network interface 
#77 
#39 
#39 
#42 


| 12. Facility Code repeated 


16. Facility Value conflict (e.g., combination not supported); Invalid Facility Req. | 65 | 
17. CCITT-specified DTE facility code or parameter not | Invalid Facility Req. 
not allowed or invalid | | 


18. Call user data larger than 128 (if Fast Select Local Procedure Error 
facility requested) 


19. Call user data present (if Fast Select facility Local Procedure Error 
not requested) 


20. The INCOMING CALL packet indicated Fast Select Local Procedure Error 
| with restriction on response 


Some networks invoke the ERROR #74 procedure if the address length fields are not equal to '0' 
in the CALL_ACCEPTED packet, except when the Called Line Modified Notification facility is 
present in the facility field. 

However, this violates American National Standards Institute ANS X3.100 

and is not recommended. 


VVVVVVVVVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 
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CLEAR REQUEST Packet | Specific 


‘Diagnostic 
Error Condition Cause 
. Packet not octet aligned Local Procedure Error 


> Packet too short Local Procedure Error 


VVVVVVVVVVVVVVVVVVVVVVVV VV VV 


Packet length incorrectly larger than 5 octets Local _Procedure Error co 


4. Calling DTE address length #0 (at any eines called DTE Local Procedure Error 
address length #0 except when the Called Line Address __ 


Modified Notification facility is present in clearing a 
call in p3. 


5. Invalid called DTE address when the Called Line Address | Local_Procedure_Error #67 
Modified Notification facility is present in clearing a 
call in state p3 (see Note 1 under A) 

6. Value of the facility length field greater than 109 Local Procedure Error | #69 


| 
7. No combination of facilities could equal facility length | Local Procedure Error , #69 


8. Facility length larger than remainder of packet | Local Procedure Error | #38 


Facility Code not allowed Invalid_Facility Req. 


Facility Value not allowed or invalid Invalid Facility Req. 
| 
ll. Class coding of the facility corresponding to a length Local Procedure Error | 
of parameter field larger than remainder of packet | 


! 


12. Facility _Code repeated Local Procedure Error 


13. Call_Deflection Selection facility requested when the Invalid_Facility Req. 


maximum number of call] redirections and call deflections 
is reached 


Call Deflection Selection facility requested after Invalid Facility Req. 
timer expiration 
15. Clear_User_Data larger than 128 (if Fast Select facility | Local Procedure Error 
requested) 
16. Clear_User Data present (if Fast Select facility Local_Procedure_Error 
and Call Deflection facility not requested) 
17. Clear_User_Data larger than 16 (if Fast Select facility Local_ Procedure Error br 


requested) 
Some networks invoke the ERROR #81 procedure if the Clearing Cause 
field is not “DTE_Originated" in the CLEAR_REQUEST packet. 


“peer oat aie —*d  er | 
2 ot arn eats cr | 


Specific 
Diagnostic 
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TABLE C 4: Actions taken by the DCE on Receipt of Packets in a given State of the Packet Layer 
DTE/DCE Interface as Perceived by the DCE: Data Transfer (Flow Control and Reset) 
on Assigned Logical Channels 


State of the interface as | DATA TRANSFER p4 


perceived by the DCE 
DIE Reset _| DCE Reset_ 


Request Indication 


Flow Control _ 


Packet from the DTE Ready 
with assigned logical channel dl 


| - d2 3 

RESET REQUEST | NORMAL DISCARD NORMAL 
| | (d2) 3 (d1) 

DTE_RESET CONFIRMATION | ERROR ERROR NORMAL 
| (d3) #27 (d3) #28 (d1) 

NORMAL ERROR ~ DISCARD 


(d1) (d3) #28 


ERROR | — ERROR DISCARD 
| (d3) (d3) 
| #41 | #41 
| ERROR =| _—_ERROR DISCARD 
| — (d3)-4#38« |S (d3) #38 
ERROR | ERROR DISCARD 
(d3) #33 | (d3) #33 
| ERROR | ERROR DISCARD | 
| (d3) #35) | (d3) #35 | 
| ERROR =| ~— ERROR. |_—« DISCARD 
| (d3) #37. «| (d3) #37 | 


DATA, [INTERRUPT] OR FLOW CONTROL 


RESTART REQUEST, DTE RESTART CONFIRMATION or 
or REGISTRATION with LCI -=x'000' 


Packet having a PTI which is shorter than '1' octet 


Packet having a PTI which is undefined or not supported 
(j.e., REJECT or REGISTRATION) 


Invalid packet type on a PVC 


| REJECT PACKET NOT SUBSCRIBED 


With reference to Table C 4: 


ERROR (r3), #x: 


The DCE discards the received packet, indicates a reset by transmitting to 
the DTE a RESET_INDICATION packet, with the Cause 
“Local_Procedure_Error” and the Diagnostic #x, and enters state d3. The 
distant DTE is also informed of the reset a RESET_INDICATION packet, with 
the Cause “Remote_Procedure Error” (same Diagnostic). 


NORMAL (di): 


Provided none of the following error conditions or special situations have 
occurred, the actions taken by the DCE follows the procedure defined in § 4: 


— lf the packet exceeds the maximum permitted length, is too short, or 
is not octet aligned, (see rule 2 in the introduction to this Appendix), 
the DCE will invoke the ERROR #39, #38 or #82 procedure, respec- 
tively. | 
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some networks may invoke the ERROR #81 procedure if the reset- 
ting Cause field in the RESET REQUEST packet does not have the 
value “DTE_ Originated.” 


Some networks may invoke the ERROR #83 procedure if Q-bit is not 
the same value within a complete packet sequence. 


If the Ps or Pr received is not valid, the DCE will invoke the ERROR 
#1 or #2 procedure, respectively. 


The DCE will consider the receipt of a 

DTE_INTERRUPT CONFIRMATION packet which does not corre- 
spond to a yet unconfirmed DCE_INTERRUPT packet as an error and 
will invoke the ERROR #43 procedure. The DCE will consider a 
DTE_INTERRUPT packet received before a previous 
DTE_INTERRUPT packet has been confirmed as an error, and will 
invoke the ERROR #44 procedure. 


If the network has a temporary inability to handle data traffic for a 
permanent virtual circuit (see § 4.2), and if the packet is a DATA, 
INTERRUPT, Flow_Control or RESET REQUEST packet received in 
State d1, the DCE shall transmit to the DTE a RESET INDICATION 
packet with the Cause “Network _Out-of-Order” and enter state d3 
(DATA, INTERRUPT or Flow_Control packet) or d1 (RESET REQUEST 
packet). 
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Appendix D. DCE Time-outs and DTE Time-limits 


Packet Layer DCE Time-outs and DTE Time-limits. 


D.1 DCE Time-Outs 


Under certain circumstances, this specification requires the DTE to respond to a 
packet issued from the DCE within a stated maximum time. 


Table D_1 covers these circumstances and the actions that DCE will initiate 
upon expiration of that time. 


The time-out values used by the DCE will never be less than those indicated in 
Table D_1. 


D.2 DTE Time-Limits 


Under certain circumstances, this specification requires the DCE to respond to 
a packet from the DTE within a stated maximum time. The actual DCE 
response times should be well within the specified time-limits. The rare situ- 
ation where a time-limit is exceeded should only occur when there is a fault 
condition. 


To facilitate recovery from such fault conditions, IBM SNA X.25 DTEs incorpo- 
rate timers. The time-limits given in Table D_2 are the lower limits of the times 
a DTE should allow for proper operation. A time-limit longer than the values 
shown may be used. Suggestions on possible DTE actions upon expiration of 
the time-limits are given in Table D_2. 


Note: 


A DTE may use a time shorter than the value given for T21 in Table D_2. 
This may be appropriate when the DTE knows the normal response time 
of the called DTE to an incoming call. In this case, the timer should 
account for the normal maximum response time of the called DTE and 
the estimated maximum call set-up time. 
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Table D1: DCE_Time-Outs Actions taken when the Time-out expires 


| 
| Local Side | Remote Side 
VOLE Starts When j Normally Terminated When 


Time—Out 


lst Time | 2nd Time | Ist Time 
DCE sends ‘bce leaves state r3 See See See 
RESTART i(i.e., RESTART CONFIRM. lal la2 1b2 
INDICATION |or RESTART REQ. rcvd) below below below 
eee Sans 
T11 DCE sends DCE leaves state p3 See See See See 
INCOMING CALL] (e.g., CLEAR REQ., CALL Zal 2a2 2b1 2b2 
(ACC. or CALL REQ. revd) below below be low below 
DCE sends DCE leaves state d3 See > See See See 
RESET i (e.g., RESET CONFIRM. or 3al 3a2 3b1 3b2 
INDICATION pees REQUEST received) below below below ~ below 
os ee ne — 
p7 ‘DCE sends ‘DCE leaves state p/7 See | see See See 
ee Meets CLEAR CONFIRM. or 4al 4a2 4b] Ab2 
| INDICATION -CLEAR REQUEST received) below | below be low below 


| 
i i 


ro nee perenne sangeet eee ttl 


With reference to Table D_1: 
Actions to be taken by the DCE on expiration of time-out: 
1. 110: 
a. at the LOCAL DTE/DCE interface the: 


1) FIRST time it occurs: 
DCE reamins in r3, signals a RESTART_INDICATION (local 
procedure error #52) again, and restarts time-out T10. 

2) SECOND time it occurs: | 

- DCE enters the r1 state and may issue a DIAGNOSTIC 
packet (#52). 


b. at the REMOTE DTE/DCE interface the: 


1) FIRST time it occurs: 
For permanent virtual circuits, DCE may enter the d3 state 
signalling a RESET INDICATION (remote procedure error 
#52). | 

2) SECOND time it occurs: 
For permanent virtual circuits, DCE may enter the d3 state 
signalling RESET INDICATION (remote procedure error #52). 


2. ¥1%: 
a. at the LOCAL DTE/DCE interface the: 


1) FIRST time it occurs: 
DCE enters the p/ state signalling a CLEAR_INDICATION 
(local procedure error #49). 

2) SECOND time it occurs: 
Not applicable. 


b. at the REMOTE DTE/DCE interface the: 


1) FIRST time it occurs: 
DCE enters the p/ state signalling a CLEAR_INDICATION 
(remote procedure error #49). | 
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2) SECOND time it occurs: 
Not applicable. 


3. 712: 
a. at the LOCAL DTE/DCE interface the: 


1) FIRST time it occurs: 
DCE remains in d3, signals a RESET INDICATION (local pro- 
cedure error #51) again, and restarts time-out T12. 

2) SECOND time it occurs: 
For virtual calls, DCE enters the p7 state signalling 
CLEAR_INDICATION (local procedure error #51). For perma- 
nent virtual circuits, DCE enters the d1 state and may issue 
a DIAGNOSTIC packet (#51). 


b. at the REMOTE DTE/DCE interface the: 


1) FIRST time it occurs: 

DCE may enter the d3 state signalling a RESET INDICATION 
(remote procedure error #51). 

SECOND time it occurs: 

For virtual calls, DCE enters the p7 state signalling a 
CLEAR_INDICATION (remote procedure error #51). For per- 
manent virtual circuits, DCE may enter state the d3 state 
signalling a RESET INDICATION (remote procedure error 
#51). 


2 


wee” 


A TAQ. 
4. 113: 


a. at the LOCAL DTE/DCE interface the: 


1) FIRST time it occurs: 
DCE remains in p7/ signalling a CLEAR_INDICATION (local 
procedure error #50) again, and restarts time-out T13. 

2) SECOND time it occurs: 
DCE enters the p1 state and may issue a DIAGNOSTIC 
packet (#50). 


b. at the REMOTE DTE/DCE interface the: 


1) FIRST time it occurs: 
Not applicable. 

2) SECOND time it occurs: 
Not applicable. 
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| TABLE D 2: DTE_Time-Limits (#4) 


Preferred Action to be taken 
when time-limit expires 
(#5) 


Normally Terminated when 
(#3) 


DTE leaves state r2 (j.e.,RESTART| Retransmit the RESTART REQUEST 
REQUEST or RESTART CONFIRM. rvcd) 


‘OTE sends 
secs. CALL_REQUEST 


DTE leaves state p2 (e.g., CLEAR 
IND, CALL_CONN. or INC_CALL rcevd) 


Transmit a CLEAR-REQUEST 
(#6) 


For virtual calls, retransmit 
the RESET REQUEST or transmit 
a CLEAR_REQUEST. 

For permanent virtual 
circuits, retransmit the 
RESET REQUEST (#2) 


T22 | 180 d2 DTE sends DTE leaves state d2 (e.g., the 
Secs. RESET _ RESET CONFIRMATION or RESET_ 
REQUEST INDICATION is received) 


T23 ; 180 p6 ‘OTE sends ie leaves state p6 (e.g., CLEAR) Retransmit the CLEAR_REQUEST 


secs. | CLEAR _REQ. ‘CONFIRM, or CLEAR_IND. received) | (#2) | 
T24 60 p4 ‘DIE sends a Transmit a RR or RNR packet 
(#7) |Secs. ‘packet with a (or a DATA or REJECT packet if 
Pry Tar Cage available for transmission) 
RR, REJECT, reflecting the current window 
RNR or DATA 


For virtual calls, transmit 
a CLEAR_REQUEST. 

For permanent virtual 
circuits, transmit a 
RESET_REQUEST. 


| Transmit a RESET REQUEST 


Retransmit the REJECT packet 
& restart 1727 


T25 | 200 p4 re sends a 
| (#7, |Secs. {DATA packet 

#8) lor DTE's win- 
idow is rotat— 
ed but there 
are still 
outstanding 
DATA packets 


There are no outstanding DATA 
packets in the window 


DTE sends 
INTERRUPT 


DTE receives an INTERRUPT_ 
CONFIRMATION 


DIE received the first 
retransmitted DATA packet 


“Es |" 
va 


DTE sends 
REJECT 


(#9) 


yA 


ae 
Retransmit the REGISTRATION_ 
REQUEST but should at some 
point recognize that the On_ 
Line Facility Registration 


Any 
secs. 
facility is not offered 


(#) — Reference to note (#). 


With reference to Table D_ 2: 


OTE sends 
REGISTRATION 
REQUEST 


DTE receives REGISTRATION 
CONFIRMATION or a DIAGNOSTIC 
packet 


1. After unsuccessful retries, recovery decisions should be taken at higher 
layers. 


2. After unsuccessful retries, the logical channel should be considered out-of- 
order. The restart procedure should only be invoked for recovery if rein- 
itialization of all logical channels is acceptable. 


3. The receipt or sending of a packet belonging to a state of higher priority will 
also cause the timer to normally terminate. For example, the receipt of a 
RESTART_INDICATION packet after having transmitted a RESET REQUEST 
packet will also cause timer T22 to normally terminate. 
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4. Some earlier IBM SNA X.25 DTEs used 200 seconds for all timeouts. 


5. When (re)transmitting a RESTART REQUEST, CLEAR REQUEST, or 
RESET REQUEST packet, the DTE should indicate the cause as “DTE 
Originated.” The diagnostic when T21 or T26 expires should indicate expi- 
ration of the corresponding timer. The diagnostic when any other timer 
expires may indicate expiration of the corresponding timer or the original 
error. 


6. In a DTE/DTE environment, the DTE which maintains its role as a DTE for 
the purpose of resolving cali collision should not terminate timer T21 upon 
receipt of an INCOMING CALL packet. 


7. T24, 725, T27, and T28 are needed only if the associated procedures are 
used. 


8. Although the DTE starts this timer when transmitting the corresponding 
packet, a DCE (or DTE if DTE/DTE) is not obligated to respond to this packet 
in such a timely fashion so as to prevent the transmitting DTE’s timer from 
expiring. Therefore, such a timer should be used with caution. 


9. It is permissible to transmit a RESET REQUEST packet when this timer 
expires (i. e., R25 and R27 are set to zero). 


Table D3: Retry Limits 


| 
Retransmission | Description | Default Action When Retransmission 
Count | Value (2); Count is Surpassed (Note 3) 
R20 Number of times a RESTART REQUEST 1 Notify the appropriate 
(Restart Request! packet is retransmitted requesting entity 
Retransmission restarting of the Packet Layer entity 
Count) — ; 


Number of times a RESET REQUEST 1 For a Virtual Call, transmit 


R22 
(Reset Request packet is retransmitted requesting a CLEAR REQUEST packet — 
Retransmission resetting of the logical channel State p6 (Note 4) 


For a Permanent Virtual Circuit 
notify the appropriate entity 


Count) 


‘Number of times a CLEAR REQUEST 
packet is retransmitted requesting 
clearing of the Virtual Call 


R23 Notify the appropriate entity 
(Clear Request 
Retransmission 


Count) 


Transmit a RESET REQUEST 
packet — State d2 (Note 4) 


R25 
(Data Packet 

Retransmission 
Count (Note 5) 


Number of times DATA packets are 
retransmitted 


Number of times a REJECT packet is 
retransmitted requesting retrans— 
mission of the same DATA packet 

(i. e., same Pr value) 


Number of times a REGISTRATION_ 
REQUEST is retransmitted 


R27 
(Reject Retrans— 
mission Count) 

(Note 5) 


Transmit a RESET REQUEST 
packet — State d2 (Note 4) 


R28 Notify the appropriate entity 
(Registration 
Request Retrans-— 
mission Count 


(Note 5) 


With reference to Table D_3: 
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. It is permissible to implement only the procedures associated with the 


default values. 


. With a default value of 1, the associated procedure is performed twice: 


once for the original transmission and once for a retransmission. To 
ensure proper operation because of the possibility of collisions, R20, 
R22, and R23 should never be set to 0. 


. If the state of the logical channel changes as a result of the action 


shown, then the new state is indicated. 


. When the DTE transmits a CLEAR_REQUEST or RESET REQUEST 


packet, the cause indicates “DTE Originated” and the diagnostic indi- 
cates that the corresponding timer expired or retransmission count was 
surpassed. 


. R25, R27, and R28 are needed only if the associated procedures are 


used. 


Diagnostic Codes 


Coding of X.25 Network Generated Diagnostic fields in CLEAR, RESET and 


RESTART INDICATION and DIAGNOSTIC Packets. 


Table E_1: DCE Diagnostics 


(Notes 1, 2 and 3) 
NO ADDITIONAL INFORMATION. . 2. . 2. 1 ee eo we ee 
FAVS de PS nb Se lee Sen We Aad es ak ah Ser Ge he ie 
TV AGG SPR As Se. eee et was es ee ee OB “es eee. re ee es 


PACKED LYRE: INVALID sewer ce: ae Meco Seow) cis WS, 5 wt AT Ge es 0001 000080 
POPS Cale: FL sh rey te a, Se ee ek: Ae O'OGed 30° O01 
PO SGGCO 2%. a: oo ae oe ere Se EOS PO, (0001 00180 
POPS tate ie. exe Gy Ge once Gee ee, ae ots hd 7 r ©8001 0011 
POP VStALCe DY a: & a: bee: Sioa OR Gee a a we eS 0001 0100 
ROY SLOUES D2 su Sw, aver eA ae RoE Se ee Ee i 0001 0101 
POM StOEG DS. e e- a. G4 ee er a ee ee es ee 0001 0110 
POU SUGCE 04 te 4. eee oe ae AU we nh ec Ge es BR 0001 0111 
POR Staves: i S-eo dick Sica ee. Ho Be aL REG 0001 1000 
ROMS Ea DODO! ee oh) as Shee gar Cartas se ee Lee ees Gor id Oe she, Se 8001 1001 
ROM SEALE Os 6 vee alae noah OW sah cae Gi! Soe ES 00 0) 10:1 8 
POP USEGLC GL as Ahie adele Bred ow, eee Re ve we oe Q@001 31011 
POI S UGC U2: ca -ns de wes whe yt Sel I ae eb ek eee ay J et a 0001 1100 
POT Sete US s cee te Se aly ok SS Ba ea ee 1 Oe Oe Oind 2¢ 
1F;} 0001 1111 31 


PACKET. GE ALLOWED 5. sce a) Gece ee a he a we ae 
Unidentifiable packet..« . 4 « dp 4 ee ew Wk ws 
Call on one way logical channel. ...... ee» 
Invalid packet type on a PVC. . 1... 6 ee wae 
" Packet on unassigned logical channel... ..... 
Reject not subscribed to... .. 2+ eo ee eee 
Packet too short ...... en el Tole EE ey Sey ae 
Packet: G00) 10NGs a 47a ai as A aoe ee 
Invalid general format identifier. ........ 
Restart or Registration packet with LCI # x'000' . 
Packet type not compatible with facility ..... 
Unauthorized interrupt confirmation. ....... 
Unauthorized interrupt . .. 2. 6. 2 ee ee eww 
Unauthorized reject. . . 1. 6 1 ew ees Ns cates (ae 2% 


Rm OFM Or OF OF OF Oe © 


eoeoocnoqaonoqcncoqnaqoon a 
eoonrceqanododoqnrcncncncooqonrdaooad a 
feed pet pede edeed fed  peet  fed peed bed ped  pe ft 
Oo ocroqodooqnooqooqoo9n ® 
~~ HH PH OOD ODOoOooe © 
KH OOO OF KF KF KH © OO OQ 
Oore re OOK KF OOrrFK CoO 


e 
@ 
° 
e 


punt 
po 
~— 


TENE EXPIRED ay sae Se he ee er OS 
For INCOMING CALL. . 2. 6 6 ts we ee 
For CLEAR_INDICATION. ......... ‘ 
For RESET INDICATION. . 2. 2 1 ee ew wo 

For RESTART. INDICATION w. v6.4 4) @ 4 a Sseu4! @ 
For Call Deflection. . . . . «ew ees 
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TABLE E_1: DCE Diagnostics — Continued H | Bits 


E Decimal 
Xi 8765 4321 

CALL SETUP, CALL CLEARING or REGISTRATION PROBLEM. . 40;0100 0000 64 
Facility/registration code not allowed. ..... 41/0100 0001 65 
Facility/registration parameter not allowed... . 42;010060 001080 66 
Invalid called address . 1... 2 2 eee eevee 43;0100 08011 67 
Invalid calling address. . .. 2. 2. 2 ee ee eee 44;';0100 0100, ~~ 68 
Invalid facility/registration length. ...... 45;0100 0101 69 
Incoming call barred . 2... 2. 2 2 eee eevee 44;0100 0118 70 
No logical channel available. .......... 47;0100 0111 71 
Cal COAUS TON: 4. He Sie S We Pe ee GS A 48;010060 10080 72 
Duplicate facility requested. ..... Tee, “dee <5 49|/0100%108601 73 
Non-zero address length. ... 2... 2.2. ee eee 44;0106 101080 74 
Non-zero facility length... ......e ees 48;}0100%1011 75 
Facility not provided when expected. ....... 46,0100 1100 76 
Invalid CCITT-specified DTE facility ....... | 40/0100 1101 77 
Max # of call redirections or deflections exceeded 4£;010041110 78 
4F};@100 1111) 79 
NISCELEANEOUSS: eo vasce? aul &- On -6- we E.G dy eR, “GE We 50;0101 0000 80 
Improper cause code from DIE. ......+..-., 51;0101 0001 81 
Not aligned octets <6. 4.4 e695 Ga © ew ee 5210101 0010 82 
Inconsistent Q bit setting. ..... gi ace er Gs 53 }0101 0011 83 
0101 0100 84 


NUT PRG DEMS oe te- Se A es Co a a bs Gn ee BT ee Wee 54 
NON ASSIGNED 


INTERNATIONAL PROBLEM 
Remote network problem. . 
International protocol problem 
International link out-of-order 
International link busy 
Transit network facility problem 


Remote network facility problem 
International routing problem 
Temporary routing problem 
Unknown called DNIC 

Maintenance action (see Note 4) 


RESERVED FOR NETWORK SPECIFIC DIAGNOSTICS 


With reference to Table E_1: 
Notes: 


1. Not all Diagnostic Codes need apply to a specific network, but those 
used are as coded in Table E_1. 


2. A given diagnostic need not apply to all packet types (i.e., 
RESET INDICATION, CLEAR_INDICATION, RESTART_INDICATION, 
REGISTRATION CONFIRMATION and DIAGNOSTIC packets). 


3. The first diagnostic in each grouping is a generic diagnostic and can be 
used in place of the more specific diagnostics within the grouping. The 
decimal’’0’ Diagnostic Code can be used in situations where no addi- 
tional information is available. 
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4. This diagnostic may also apply to a maintenance action within a 
national network. 
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Appendix F. On-Line Registration Facilify Applicability 


Applicability of the On-Line Facility Registration facility to other facilities is 
Summarized in Table F-1. 


Table F-1: Registration Applicability 


Porstnrsncancraesies [es |v fr Le 
Non-Standard Default Window Sizes ‘ 
eff 
reunite pea fy | w 
oe 
fee 


Bilateral CUG Related Facilities 


es 
ww 


| Fast Select 


Fast Select Acceptance 


Reverse Charging 


| Reverse Charging Acceptance 


| Local Charging Prevention | 6.20 
| NUI_Related Facilities | 6.21 a 


Charging Information 
(per interface basis) 
(per call basis) 


Def. = Specification section where defined. 
Reference to note #. 
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RPOA Related Facilities 
RPOA Subscription 
RPOA Selection 


Call Redirection or Call Deflection_ 
Notification 


Transit Delay Selection _and_ Indication 6.27 


Allocation_of Logical Channel Type Ranges 


Def. = Specification section where defined. 
(#) = Reference to note #. 


With reference to Table F-1: 


Notes: 


1. 
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Negotiable in REGISTRATION REQUEST and 
REGISTRATION CONFIRMATION packets. 


. Indication in REGISTRATION CONFIRMATION packets whether the 


facility is supported by the DCE. 


Negotiable only when every logical channel used for virtual calls is tn 
State pt. 


. Under consideration for further study by the CCITT. 


. Negotiation of one-way logical channel ranges is accomplished by allo- | 


cation of logical channel type ranges negotiation. 


AMM nm ™| LF) MA ANA NAN MAA NAA NAA ANUNAARAAADYDM 


TABLE F-2: Packet Layer Optional User Facilities 


Optional User Facility 


On-line Facility Registration 
Extended Packet Sequence Numbering 
D-bit_ Modification 
Packet_Retransmission 


- Incoming Calls Barred 


Outgoing Calls Barred 

One-way Logical Channel] Outgoing 
One-way_Logical_ Channel Incoming 
Nonstandard Default Packet Sizes 
Nonstandard Default _Window_Sizes 

Default _Throughput_Class_ Assignment 

Flow Control] Parameter Negotiation 
Throughput_Class Negotiation 

Closed User Group Related Facilities 

~Closed_User_Group 

~Closed User Group With Outgoing_Access 

~Closed User Group _With_Incoming_Access 

—Incoming Calls Barred Within_A_Closed_ 
User Group 

—Outgoing Calls Barred_Within_A Closed_ 
User Group 

—Closed User Group Selection 

-Closed User Group With _Outgoing Access __ 
Selection 

Bilateral Closed 4ser Group Related Facilities 

—Bilateral Closed User Group 

—Bilateral Closed User Group With Outgoing_ 
Access 

—Bilateral Closed User Group Selection 
Fast Select 

Fast_Select_ Acceptance 

Reverse Charging 

Reverse Charging Acceptance 

Local Charging Prevention 

NUI_ Subscription 

NUI Override 

NUI Selection 

Charging Information 

RPOA_ Subscription 

RPOA Selection 

Hunt _Group 

Call Redirection 

Call Deflection Subscription 

Call Deflection Selection 

Call Redirection or Deflection Notification 
Called Line Address Modified Notification 

Transit Delay Selection And Notification 


*VC = Virtual Call 


Classification! Agree For | Applies Applies to 
(1) Period of | Per Call? DTE/DTE 
VC* PVC* Time? Operation? 


(2) 


(2) 
(3) 
(3) 


|_ rrr > 


(4) 
(4) 
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PVC = Permanent Virtual Circuit 
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Notes: 
1. The classification indicates whether the facility: 
e must be provided by an X.25 network (E - Essential facility), 


* may optionally be provided by an S.25 network (A - Additional 
facility), or 


° does not apply (shown as a dash) 
as given in CCITT Recommendation X.2. 


2. Ina DTE/DTE environment, use of these facilities is agreed to sepa- 
rately for each direction of transmission. 


3. In a DTE/DTE environment, these facilities may apply only through the 
use of the On-line Facility Registration Facility. 


4. These per Virtual Call facilities cannot be used unless the corre- 
sponding facility has been agreed to for a period of time. 


5. In a DTE/DTE environment, use of this facility requires agreement by 
both DTEs for a period of time. | 
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G.1 


CCliTT-Specified DTE Facilities to support the OSI.Network_Service are 
described in “Introduction” through “Coding of the Facility Code Fields” on 
page G-3. 


Introduction 


The optional CCITT-Specified DTE facilities described in this section apply only 
to Virtual Call service. 


The facilities described in this Appendix are intended to support end-to-end sig- 
nalling required by the OSI Network service. They follow the 
CClTT-Specified DTE facility marker defined in § 7.1 and are applicable to both 
DTE/DCE and DTE/DTE operation. These facilities are passed unchanged 
between the two packet mode DTEs involved. 


Procedures for use of these facilities by DTEs are specified below. Subsequent 
provision of X.25 facilities to be acted on by public data networks ts for further 
study. Coding of the facilities in this Appendix is defined here in order to facili- 
tate a consistent facility coding scheme in such future evolution. 


s G.1.1 Procedures for optional CCITT-Specified_DTE facilities 


s G.1.1.1 Calling Address Extension 


S 
S 
S 
S 
S 


Pn nannnnnnn 


Calling Address Extension is an optional CCITT-Specified_DTE facility which 
may be used for a given Virtual Call. It provides for the transparent 
conveyance in CALL REQUEST and INCOMING CALL packets of the calling OSI 
Network Address. The calling OSI Network Address is passed to a higher layer 
entity in the called DTE. 


G.1.1.2 Called Address_Extension 


Called Address Extension is an optional CCITT-Specified DTE facility which 
may be used for a given Virtual Call. It provides for the transparent 
conveyance in CALL REQUEST and INCOMING CALL packets of the called OSI 
Network Address supplied by a higher layer entity in the calling DTE. It also 
provides for the transparent conveyance of the responding OSI Network 
Address in CALL ACCEPTED and CALL_ CONNECTED packets (for the case of 
call acceptance) and in the CLEAR REQUEST and CLEAR INDICATION packets 
(for the case of call rejection). The responding OS! Network Address is passed 
to a higher layer entity in the calling DTE. 


s 6.1.1.3 Minimum_Throughput_Class_ Negotiation 


nm AA FARA HM 


Minimum_Throughput_Class Negotiation is an optional CCITT-Specified DTE 
facility which may be used for a given Virtual Call. The calling DTE indicates for 
each direction of data transmission a minimum-acceptable value for the 
throughput class by means of the Minimum_Throughput_Class Negotiation 
Facility in the CALL REQUEST packet. These two values are conveyed trans- 
parently to the called DTE in the INCOMING CALL packet. Gateways, private 
networks, and the called DTE may clear the call if resources necessary to 
support the minimum-acceptable throughput classes are not available. Gate- 
ways, private networks, and the called DTE may use the 
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Throughput Class Negotiation Facility to determine whether public data net- 
works can support the minimum-acceptable throughput classes and should 
clear the call if the public data network cannot support these values. 


The absence of this facility indicates that the calling DTE does not place a lower 
limit on the acceptable throughput class. The values conveyed by this facility. 
are supplied by a higher layer entity in the calling DTE and passes to a higher 
layer entity in the called DTE. 


G.1.1.4 End-to-End_Transit_Delay_Negotiation 


G.1.1.5 Priority 


End-to-End_Transit_Delay_Negotiation is an optional CCITT_specified facility 
which may be used for a given Virtual Call. The calling DTE indicates the 
cumulative transit delay of the Packet Layer and lower layer protocols in the 
DTE including the effects of the access line transmission rate, by means of the 
End-to-End_Transit_Delay_Negotiation Facility in the CALL_REQUEST packet. 
The cumulative transit delay value is conveyed transparently by public data net- 
works and is updated by gateways and the called DTE as the call setup.is 
progressed. Gateways and the called DTE may use the Transit Delay Selection 
And Indication Facility introduced by the preceding network in PeMcrning:y the © 
computation of the cumulative transit delay. 


In addition to the cumulative transit delay, the calling DTE may optionally indi- 
cate a desired (target) value for the end-to-end transit delay. If the target value 
is indicated, the calling DTE may optionally indicate a maximum-acceptable 
value for the end-to-end transit delay. These values, when present, are pro- 
vided by a higher layer entity in the calling DTE and are conveyed transparently 
to the called DTE in the INCOMING CALL packet. The absence of these facili- 
ties indicates that the calling DTE did not provide a target value and/or upper 
limit on the transit delay. 


Gateways, private networks, and the called DTE should clear the call if the 
cumulative transit delay exceeds the maximum-acceptable transit delay, if spec- 
ified. The maximum-acceptable transit delay, when present, and the cumulative 
transit delay as computed by the Packet Layer of the called DTE are passed to 
a higher layer entity in the called DTE. 


The cumulative transit delay computed by the Packet Layer of the called DTE is 

indicated in the CALL ACCEPTED packet, conveyed transparently to the calling 

DTE in the CALL_CONNECTED packet, and passed to a higher layer entity in the 
calling DTE. 


Priority is an optional CCITT-Specified_DTE facility which may be used for a 
given Virtual Call. The calling DTE may indicate in the CALL REQUEST packet 
the target and lowest-acceptable values for the priority of data on a connection, | 
priority to gain a connection, and priority to keep a connection. The values, _ 
where present, are provided by a higher layer entity in the calling DTE and are 
conveyed transparently by public data networks. : 


Gateways, private networks, and the called DTE may reduce the target values 
as necessary, and may clear the call if they cannot support the lowest- 
acceptable values. Values received by the called DTE are passed to a higher 
layer entity which will return selected values. These selected values are indi- 
cated by the called DTE in the CALL_ACCEPTED packet, conveyed transparently 
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+ G.2 Coding of the Facility Code Fields 


G.1.1.6 Protection 


to the calling DTE in the CALL_ CONNECTED packet, and passed to a higher 
layer entity in the calling DTE. 


Protection is an optional CCITT-Specified DTE facility which may be used for a 
given Virtual Call. The calling DTE may indicate in the CALL_REQUEST packet 
the target and lowest-acceptable values for protection. The values, where 
present, are provided by a higher layer entity in the calling DTE and are con- 
veyed transparently by public data networks. | 


Gateways, private networks, and the called DTE may reduce the target values 
as necessary, and may clear the call if they cannot support the lowest- 
acceptable values. Values received by the called DTE are passed to a higher 
layer entity which will return selected values. These selected values are indi- 
cated by the called DTE in the CALL_ ACCEPTED packet, conveyed transparently 
to the calling DTE in the CALL_CONNECTED packet, and passed to a epee 
layer entity in the calling DTE. 


G.1.1./ Expedited _Data_Negotiation 


Expedited Data Negotiation is an optional CCITT- Specified DTE facility which 
may be used for a given Virtual Call. The calling DTE uses the Expedited Data 
Negotiation Facility in the CALL REQUEST packet to indicate whether it wishes 
to use the expedited data transfer procedures (i. e., the interrupt procedures). 
This indication ts provided by a higher layer entity in the calling DTE. This 
facility is conveyed transparently by public data networks but may be set to 
non-use of the expedited data transfer procedures by gateways and private net- 
works that do not support them. 


If the higher layer entity in the called DTE wishes to use the expedited data 
transfer procedures and the facility received in the INCOMING CALL packet 
indicates use of these procedures, then use of these procedures is indicated in 
the CALL_ACCEPTED packet and conveyed transparently in the 
CALL_CONNECTED packet. Otherwise, non-use of the expedited data transfer 
procedures is indicated in these packets. 


The indication in the CALL_CONNECTED packet of whether use of the expedited 
data transfer procedures has been agreed to is passed to a higher layer entity. 


Table G_1 gives the coding of the Facility. Code field for each 
CCITT-specified DTE facility and the packet types in which they may be present. 
These facilities are conveyed after the CCITT-specified_DTE Facility. Marker. 
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Table G1: roan of the poe Code Field 


| Facility 


Calling. Address Extension 
Cai _Address Extension 


duals er ariservice:. 
Negotiation 

Minimum Throughput Class 
End-to-End Transit Delay 
Priority 
Protection 


Facility Code 
Bits 
8 7 6:39) 43 2.1 


Packet types in which it may be used 


Expedited Data Negotiation 


(see § 6.25.2.2) 


ie eA ke ele el a ee a 


* Only when the Call Deflection Selection facility is used 


G.3 Coding of the Facility_Parameter Field 


G.3.1 Calling Address_Extension Facility 
The octet following the Facility Code field indicates the length of the 
Facility Parameter field in octets. It has a value of n + 1, where ‘n’ is the 


> number of octets necessary to hold the calling address extension. The facility 
> | parameter field follows the length and contains the calling address extension. 
> The first octet of the Facility Parameter field indicates, in bits 8 and 7, the use 
as of the calling address extension, as shown in Table G-2. 

> : 

= Table G-2: Coding of Bits 8 and 7 in the First Octet 

eo of the Calling Extension Facility parameter field 

> 

> Use of calling address extension 

> 

> 

> To carry a calling address assigned according to CCITT 

os Recommendation X.213/1S0 8348 AD2 

> 

> Reserved 

> 

> Other (to carry a calling address not assigned according to 

2 CCITT Recommendation X.213/1S0 8348 AD2 

> 

> Reserved 

> 
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> Bits 6, 5, 4, 3, 2 and 1 of this octet indicates the number of semi-octets (up to a 
maximum of 40) in the calling address extension. This address length indicator 
> is binary coded, where bit 1 is the low order bit. 


V 


> The following octets contain the calling address extension. 


V 


If bits 8 and 7 of the first octet of the facility parameter field are coded ‘OO’, the 
following octets are encoded using the preferred binary encoding (PBE) defined 
in CCITT Recommendation X.213 and ISO 8348/AD2. Starting from the high- 
order digit of the Initial Domain Part (IDP), the address is coded in octet 2 and 
consecutive octets of the facility parameter field. Each digit, with padding digits 
applied as necessary, is coded in a semi-octet in binary coded decimal, where 
bit 5 or bit 1 is the low order bit of the digit. In each octet, the higher-order bit 
is coded in bits 8, 7,6, and 5. The Domain Specific Part (DSP) of the calling OSI 
NSAP follows the IDP and is coded in decimal or binary, according to the PBE. 
For example, if the syntax of the DSP is decimal, each digit is coded in in binary 
decimal (with the same rules applying to the DSP as to the IDP above). If the 
syntax of the DSP is binary, each octet of the calling address extension contains 
an octet of the DSP. 


NM | 
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If bits 8 and 7 of the first octet of the facility parameter field are coded ‘10’, each 
digit of the calling address extension is coded in a semi-octet in binary coded 
decimal, where bit 5 or 1 is the low-order bit of the digit. Starting from the 
high-order digit, the address is coded in octet 2 and consecutive octets of the 
facility parameter field with two digits per octet. In each octet, the higher order 
digit is coded in bits 8, 7,6, and 5. When necessary, the Facility. Parameter 
field shall be rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field. | 


ME NE NEA OY 


G.3.2 Called_Address_Extension Facility | 
The octet following the Facility Code field indicates the length of the 
Facility Parameter field in octets. It has a value of n + 1, where ‘n’ is the 
ze number of octets necessary to hold the called address extension. The facility 
> parameter field follows the length and indicates the called address extension. 


> The first octet of the Facility. Parameter indicates, in bits 8 and 7, the use of the 
> called address extension, as shown in Table G-3. 
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Table G-3: Coding of Bits 8 and 7 in the First Octet 
of the Called Extension Facility parameter field 


Use of called address extension 


To carry a calling address assigned according to CCITT 
Recommendation X.213\IS0 8348 AD2 


Reserved 


Other (to carry a calling address not assigned according to 
CCITT Recommendation X.213/ISO 8348 AD2 


Reserved 


Bits 6, 5, 4, 3, 2 and 1 of this octet indicates the numver of semi-octets (up to a 
maximum of 40) in the called address extension. This address gn indicator 
is binary coded, where bit 1 is the low order bit. 


The following octets contain the called address extension. 


If bits 8 and 7 of the first octet of the facility parameter field are coded ‘00’, the 
following octets are encoded using the preferred binary encoding (PBE) defined 
in CCITT Recommendation X.213 and ISO 8348/AD2. Starting from the high- 
order digit of the Initial Domain Part (IDP), the address is coded in octet 2 and 
consecutive octets of the facility parameter field. Each digit, with padding digits 
applied as necessary, is coded in a semi-octet in binary coded decimal, where 
bit 5 or bit 1 is the low order bit of the digit. In each octet, the higher-order bit 
is coded in bits 8, 7, 6, and 5. The Domain Specific Part (DSP) of the called OSI 
NSAP follows the IDP and is coded in decimal or binary, according to the PBE. 
For example, if the syntax of the DSP is decimal, each digit is coded in in binary 
decimal (with the same rules applying to the DSP as to the IDP above). Ifthe 
syntax of the DSP is binary, each octet of the called address extension contains 
an octet of the DSP. 


If bits 8 and 7 of the first octet of the facility parameter field are coded ‘10’, each 
digit of the called address extension is coded in a semi-octet in binary coded 
decimal, where bit 5 or 1 is the low-order bit of the digit. Starting from the 
high-order digit, the address is coded in octet 2 and consecutive octets of the 
facility parameter field with two digits per octet. In each octet, the higher order 
digit is coded in bits 8, 7, 6, and 5. When necessary, the Facility_ Parameter 
field shall be rounded up to an integral number of octets by inserting zeros in 
bits 4, 3, 2 and 1 of the last octet of the field. 
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G.3.3 Quality of Service Negotiation Facilities 


G.3.3.1 Minimum_Throughput_Class Facility 
The minimum throughput class for the direction of data transmission from the 
calling DTE is indicated in bits 4, 3, 2 and 1. The minimum throughput class for 
the direction of data transmission from the called DTE ts indicated in bits 8, 7, 6 
and 9. 


The four bits indicated each throughput class are binary coded and correspond 
to throughput classes as indicated in Table 28. 


G.3.3.2 End-to-End_Transit_Delay Facility 
The octet following the Facility Code field indicates the length in octets of the 
Facility Parameter field and has the value 2, 4 or 6. 


The first octet and second octets of the Facility Parameter field contain the 
cumulative transit delay. The third and fourth octets are optional and, when 
present, contain the requested end-to-end transit delay. If the third and fourth 
octets are present, then the fifth and sixth octets are also optional. The fifth 
and sixth octets, when present, contain the maximum acceptable end-to-end 
transit delay. The optional octets are not present in CALL ACCEPTED and 
CALL CONNECTED packets. 


Transit delay is expressed in milliseconds and is binary coded, with bit 8 of the 
first of a pair of octets being the high-order bit and bit 1 of the second of a pair 
of oclets being the iow-order bit. The vaiue of ali ones for cumulative transit 
delay indicates that the cumulative transit delay is unknown or exceeds 65,534 
milliseconds. 


G.3.3.3 Priority Facility . 
The octet following the facility code field indicates the length in, octets, of the 
facility parameter field. This may take the value 1, 2, 3, 4, 5 or 6. 


The first, second and third octets of the facility parameter field contain the 
target (CALL REQUEST packet), available (INCOMING CALL packet) or selected 
(CALL ACCEPTED and CALL CONNECTED packets) values for the priority of 
data on a connection, priority to gain a connection and priority to keep a con- 
nection, respectively. The fourth, fifth and sixth octets of the facility parameter 
field in CALL_ REQUEST and INCOMING CALL packets contain the lowest 
acceptable values for the priority of data on connection, priority to gain a con- 
nection and priority to keep a connection, respectively. When the facility is 
present in CALL REQUEST and INCOMING CALL packets, octet 2 through 6 of 
the facility parameter field are optional. For example, if the only values to be 
specified are the target and lowest acceptable values for priority to gain a con- 
nection, then the facility parameter field will contain at least.5 octets with octets 
1, 3 and 4 containing the value “unspecified”, and octets 2 and 5 containing the 
specified values. When the facility is present in the CALL ACCEPTED and 
CALL CONNECTED packets, octets 2 and 4 are optional. 


The range of specified values for each sub-parameter is O (lowest priority) to 14 


(highest priority). The value 255 (x'FF’ .) indicates “unspecified”. All other 
values (I. e., 15 through 254) are reserved. 
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The octet following the facility code indicates the length, in octets, of the facility 
parameter field. 


The two highest order bits of the first octet (i. e., bits 8 and 7) of the facility | 
parameter field specify the protection format code as indicated in Table G-4. 


Table G-4: Coding of the Two Highest Order Bits in the First 
Octet of. the Protection Format Code 


Bits | Protection Format Code 
8 7 


0 0 Reserved 


0 1 Source address specific 


ae ©. Destination address specific 


1 11 Globally unique 


The remaining six bits of the octet are reserved and must be set to zero. 


The second octet of the facility parameter field specifies the length ‘n’, in octets, 
of the target (CALL_REQUEST packet), available (INCOMING CALL packet) or 
selected (CALL ACCEPTED and CALL CONNECTED packets) protection level. 
The actual value is placed in the following ‘n’ octets. Optionally, the ‘n+3’ 
octet of the facility parameter field specifies the length ‘m’, in octets, of the 
lowest acceptable protection level in CALL REQUEST and INCOMING CALL 
packets. The actual value is placed in the following ‘m’ octets. The optional 
octets are not present in CALL ACCEPTED and CALL ACCEPTED packets. 


Note: 


The values of ‘n’ and ‘m’ are bounded by both the overall length of the 
facility (first octet), and by each other. | 


G.3.4 Expedited _Data_Negotiation Facility 


The coding of the Facility_ Parameter field is: 


bit 1 = 0 for no use of expedited data 
1 for use of expedited data 


Note: 


Bits 8, 7, 6, 5, 4, 3 and 2 may be assigned to other facilities in the future; 
presently, they are set to zero. 
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Appendix H. DTE-Generated Diagnostic Codes 


Codes transferred in the Diagnostic_Code field of CLEAR, RESET AND 
RESTART REQUEST packets generated IBM SNA X.25 DTEs are divided into 
two categories identified by the associated Cause Code. The 

Diagnostic Code transferred by IBM SNA X.25 DTEs when the associated 
Cause Code is equal to: 


x00" 

convey the CCITT/ISO-8208 Standard meaning specified in Table 
H_ 1 on SNA-to-non_ SNA connections; 
x80’ 

convey the SNA Specific meaning specified in Table H_2 on 
SNA-to-SNA connections. 
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H.1 Standard CCITT X.25/ISO-8208 DTE-Generated Codes 


Lay 


Packet 
Types 


Table H_1: CCITT/ISO-8208 Standard 
DTE Diagnostics 


No Additional Information D,Rr,C,Re,Rg 
Invalid P(S) 


Invalid P(R) 


Packet Type Invalid 
for state rl 
for state r2 
for state r3 
for state pl 
for state p2 | 
for state p3 | 
for state p4 
for state p5 
for state p6 | 
for state p7 
for state dl 
for state d2 
for state d3 
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Packet Not Allowed 0010 0000 D,Rr,C,Re 
unidentifiable packet 001090001 Rr,C,Re 
call on one-way logical channel 0010 00180 C 
invalid packet type on a PVC 00100011 Re 
packet on unassigned logical channel 09100180 D 
REJECT not subscribed to 0010 0101 Re 
packet too short . 0010 0110 D,Rr,C,Re,Rg 
packet too long 001060111 D,Rr,C,RE,Rg 
invalid General Format Identifier 00101000 D 
Restart or Registration with LCI#x'000' 00101001 Rr, C,Re 
packet type not compatible with facility | 0010 1010 C 
unauthorized interrupt confirmation 00101011 Re 
unauthorized interrupt 6001031100 Re 
unauthorized reject 00101101 Re . 


— 


Timer Expired (or Limit Surpassed) D,Rr,C,Re 


for INCOMING CALL (or CALL REQUEST) C 
for CLEAR_INDICATION (or REQUEST) D,C 
for RESET_INDICATION (or RESET REQUEST) D,C,Re 
for RESTART_INDICATION (or REQUEST) D,Rr,C,Re 


for call deflection C 


H-2 Architecture Reference _ 


Table H_1: CCITT/ISO-8208 Standard 
DTE Diagnostics — 
Continued 


facility/registration parameter 
not allowed 

invalid called address 

invalid calling address 


invalid facility/registration length 


incoming call barred 

no logical channel available 
call collision 

duplicate facility requested 
nonzero address length 
nonzero facility length 


‘Miscellaneous 

| improper cause code from DTE 
non-octet aligned 
inconsistent Q-bit settings 

NUI problem 


\Not Assigned 
| 


International problem 
remote network problem 
international protocol problem 
international link out of order 
international link busy 
transit network facility problem 
remote network facility problem 
international routing problem 
temporary routing problem 
unknown called DNIC 
maintenance action§ 


Not Assigned 


Timer Expired (or Limit Surpassed) 
for INTERRUPT CONFIRMATION 
for DATA packet retransmission 
for REJECT packet retransmission 


Call Setup/Clearing or Registration Problem; 0 1 
facility/registration code not allowed 01 


facility not provided when expected 
invalid CCITT-Specified DTE facility 
maximum redirections/deflections exceeded 


| 
Bits 
Decimal 
64 C,Rg 


8765 4321 

00 0000 

00 0001 65 C,Rg 
0100 0010 66 C,Rg 
01000011 67 C 
0100 0100 68 C 
01000101 69 C,Rg 
01006110 70 C 
01000111 71 C 
01001000 72 C 
01001001 73 C,Rg 
01001010 74 C,Rg 
01001011 75 C 
01001100 76 C,Rg 
01001101 77 C 
01001110 78 C 
01001111 79 

i i 

0101 00Ct0 go | Rr,C,Re 
01010001 81 D,Rr,C,Re 
0101 06010 82 D,Rr,C,Re 
01010011 83 Re 
01010100 84 C 
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Table H_1: 


CCITT/ISO-8208 Standard 
DTE Diagnostics — 
Continued 


DTE-Specific Signals 
DTE Operational 
DTE Not operational 
DTE resource constraint 
Fast Select not subscribed 
Invalid partially full DATA packet 
D-bit procedure not supported 
Registration/Cancellation confirmed 


Not assigned 


lOSI Network Service Problem 11110 60000 


disconnection (transient condition) 
| disconnection (permanent condition) | 
connection rejection — reason | 
unspecified (transient condition) | 
connection rejection — reason | 
unspecified (permanent condition) 
connection rejection — requested quality 
of service not available 
(transient condition) 
connection rejection — requested quality 
of service not available | 
(permanent condition) 
connection rejection — OSI network 
address unreachable (transient problem) 
connection rejection — OSI network ad— 
dress unreachable (permanent problem) 
reset — reason unspecified 
reset — congestion 
connection rejection — OSI Network 
address unknown (permanent condition) 


Higher Layer Initiated 
disconnection — norma] 
— abnormal 
— incompatible information 
in user data 
connection rejection — reason 
unspecified (transient condition) 
connection rejection — reason 
unspecified (permanent condition) 
connection rejection — requested quality 
of service not available 
(transient condition) 
connection rejection — requested quality 
of service not available 
(permanent condition) 
connection rejection — incompatible 
information in user data 
connection rejection — unrecognizable 
protocol identifier in user data 
reset — resynchronization 
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Bits | 
Decimal 
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Rr,C,Re 
Rr,Re 
Rr,C,Re 
Rr,C,Re 
C 
Re 
C,Re 
Rg 
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With reference to Table H_1: 
Notes: 


1. - A given diagnostic need not apply to all packet types. The packet 
type(s) to which each diagnostic may apply are shown where:. 


a. D=DIAGNOSTIC; Rr=RESTART REQUEST/INDICATION; 
C=CLEAR_REQUEST/INDICATION; 
Re= RESET REQUEST/INDICATION; and 
Rg =REGISTRATION CONFIRMATION; and 


b. additionally, for diagnostic codes in packets transmitted by a 
DTE: Re=CLEAR REQUEST and RESTART REQUEST; 
C=RESTART REQUEST; and 


c. hence, additionally, for packets received by a DTE operating ina 
DTE/DTE environment: Re =CLEAR_INDICATION and 
RESTART INDICATION; C=RESTART_INDICATION. 


2. - Codes in DTE-originated packets must correspond to the diagnostics 
specified here when the associated cause code is x’00’. Codes 224-255 
support the OSI Network Service Definition. 


3. - The first diagnostic in each grouping is a generic diagnostic and can 
be used in place of the more specific diagnostics within the grouping. 
The diagnostic #0 (x’00’) can be used in situations where no additional 
information is available (e.g., where the more specific diagnostics are 
not implemented). 


4. - In certain situations, multiple diagnostic codes may apply. For 
example, if a timer has expired and a (RESTART, CLEAR, or RESET) 
REQUEST packet is to be retransmitted, then the DTE may use the diag- 
nostic code associated with the original error or the corresponding 
“timer expired” diagnostic code. 


5. § - This diagnostic may also apply to a maintenance action within a 
national network. 
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H.2 SNA-Specific DTE Generated Diagnostic Codes 


Table H 2: SNA specific DTE Diagnostics iH 


(Notes 1, 2 and 3) X' 8765 4321 


Normal Initialization or Termination 00 | 0000 0000 
Invalid Ps 6011/0000 0001 
Invalid Pr 02; 0000 0010 
Invalid LLC Type oc | 0000 11080 
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Invalid Packet Type (General) 10 |} 0001 0000 16 
for State rl 1l; 0001 0001 17 
for State r2 12; 0001 0010 18 
for State r3 13} 0001 0011 19 
for State pl ; 144) 0001 G100); 20 
for State p2 ; 1/0001 0101 21 
for State p3 b AGr5 OO: 02%: 0 110 22 
for State p4 17} 90001 0111 23 
for State p5 18 ;}0001 1000 24 
for State p6 19 | 00011001 25 
for State p/ 1A | 0001 1010 26 
for State dl 1B |} 000141011 27 
for State d2 ic |} 0001411009 28 

000131101 29 


for State d3 1D 


ry 
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DCE Timer Expired (General) 
Incoming Cal] 
Clear Indication 
Reset Indication 
Restart Indication 


Unauthorized INTERRUPT CONFIRMATION 
Unauthorized INTERRUPT 


DTE Timer Expired (General) 
Call Request 
Clear Request 
Reset Request 
Restart Request 


Reject Not Subscribed to 
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Table H 2: SNA Specific DTE Diagnostics — (Cont'd) |H 


Unassigned (General) 


Invalid Called Address 
Invalid Calling Address 


Call Collision 
Unassigned (General) 


QLLC Error (General) 
Undefined C-field 
Unexpected C-field 
Missing I-field 
Undefined I-field 
I-field Too Long 
Frame Reject Received 

| Header Invalid 

Data Received in Wrong State 
Time-out Condition 
Nr Invalid 
Recovery Rejected or Terminated 
XID Negotiation in Wrong State 
ELLC Time-out Condition 
'Q' Bit Discrepancy 


PSH Error (General) 
Sequence Error 
Header too Short 
PSH Format Invalid 
Command Undefined 
Protocol Invalid 
Data Received in Wrong State 


Time-out Condition 69 | 011016001 105 


PAD Error (General) 
PAD Access Facility Failure 
SDLC FCS Error 
SDLC Time-out 
SDLC Frame Invalid 
I-field too long 
SDLC Sequence Error 
SDLC Frame Aborted 
SDLC FRHR Received 
SDLC Response Invalid 
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1 1 
11 
1 1 
11 
11 
11 
1. 4 
11 
11 
11 


oy 
[omy 
— 


Invalid Packet Type 
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PAD Inoperable 
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Table H_2: SNA Specific DTE Diagnostics ~— (Cont'd) 


DTE-Specific (General) 
8100 DPPX-Specific 
INN QLLC-Specific 


INN_QLLC-Specific 
| Network Specific 


| DDX-P RNR Packet Received 


Packet Not Allowed (General) 
Invalid 'M' bit Packet Sequence 
Invalid Packet Type Received 
Invalid Packet on PVC 
Unassigned LC 
Diagnostic Packet Received 
Packet too short 
Packet too long 
Invalid GFI 
Not Identifiable 
Not Supported 
Invalid Ps 
Invalid Pr 
Invalid 'D' bit Received 
Invalid 'Q' bit Received 


DTE Specific (NPSI Gate/Date) (General) 
No LU-to-LU Session 
ABEND 703 In Progress 
Cancel CHAIN Command 


DTE Specific (General) 
Termination Pending 
Channel Inoperative 
Unauthorized Interrupt Confirmation 
Unauthorized Interrupt Request 


PU Not Available 

Inactivity Time—Out 

Incompatible Line Configuration 

RESET INDICATION for PAD, translated from signal 
DTE Not Operational 
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Decima | 


144 
145 


192 
193 
194 
195 
196 
197 
198 
199 
200 
201 


207 
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OO 


| 
Table H 2: SNA Specific DTE Diagnostics - (Cont'd) |H | Bits | 
E Decimal 


Xi} 8765 4321 


a a GEER 


Resources (General) pb0; 1101 0000 208 
Buffers depleted Die ted b-O E00 1 209 
PIU too long D2 }1101 0010 210 

DR ie Oe 2k Pd 223 

Local Procedure Error (General) FO |} 1110 0000 224 
Packet. with LC=0 not Received El; 1110 0001 225 
RESTART, DIAGNOSTIC, REGISTRATION on LCI # x'000' E2}/1110 00180 226 
INCOMING CALL Received on Wrong LC F3}/1110 0011 227 
Facility not Subscribed Eé;1110 0100 228 
Packet Not RESTART or DIAG on LCI = x'000' ES.) 1 DP 10: @ 1-0-4 229 
Facility Parameters not Supported E6 i} 11100110 230 
Facility not Supported EZ.) 2-2 -7.0.°0. 1. PJ 231 
Unexpected Calling DTE ; Fs} Pili d@ 1:80 9 232 
Invalid 'D' bit Request E9 | 1110 1001 233 
RESET INDICATION on Virtual Cal] ' FA} 1110 1010 | 234 
Invalid Protocol Identifier f eB] i1te 10114) 235 
Connection Identifier Mismatch | € 1110311600) 236 
Missing Cause/Diagnostic Code 111031101 

Pit? bE 
Pb Tet ta 


Miscellaneous 


Link Reset 


With reference to Table H_2: 
Notes: 


1. All diagnostic codes are not necessarily used by all DTEs, but those that 
are used have the meaning indicated. 


2. The first diagnostic in each grouping is a generic code that may be 
used in place of the more specific codes within the group. 


3. These codes, set by transmitting DTEs, in CLEAR, RESET and RESTART 
packets that also have the Cause_ Code set to x‘80’ transferred on 
SNA-to-SNA connections, are normally del'vered to the remote DTE in a 
corresponding INDICATION packet by DCEs. However, DCEs may over- 
ride DTE requests. In this event, DCEs place a network-generated non- 
zero Cause Code less than 128 in the Cause field and insert the network 
Diagnostic Code (see Appendix E) in the Diagnostic Code field of the 
resulting INDICATION packet delivered to the remote DTE. 
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Appendix I. Description of DTE Packet Layer Actions 


1.1 Introduction 


Actions taken by IBM SNA X.25 DTEs as a result of packets received in the 
various States of the packet layer DTE/DCE interface, as perceived by the DTE, 
are presented in this appendix as a succession of chained tables, where: 


Figure I-1 on page I-2 is applicable for Any State 

Figure I-2 on page I-3 is applicable for Restarting States - (r1, r2 & 
r3) 

Figure I-3 on page I-6 is applicable for Call Setup and Clearing 
States - (p1, p2, p3, p4, p5, p6 & p7/) 

Figure |-4 on page I-8 is applicable for Data Transfer States - (d1, 
d2 & d3) 

Figure I-5 on page I-9 is applicable for Interrupt States - (i1, 12, j1 
& J2) 

Figure I-6 on page I-10 is applicable for Flow Control States - (f1, 
f2, g1 & g2) 


Note: 


The Interrupt and Flow Control States are independent of one 
another and exist in parallel. That is, a logical channel Is 
simultaneously in one of the two ‘i’ states, one of the two j’ 
states, one of the two ‘f states and one of the two ‘g’ states 
whenever the interface in is the Flow Control Ready State 
(d1). 


1.1.1 Rules and Conventions 
The following rules and conventions apply for all the tables in this 


appendix. 


+ +4 


IBM SNA X.25 DTEs discontinue normal processing of a received 
packet when an error is encountered and the order of packet 
decoding and checking is not specified. Thus, a single diagnostic 
code is associated with any error indicated by the DTE when more 
than one error is associated with a packet. 


e Actions taken by the DTE are specified in the tables as: 


— DISCARD: the DTE discards the received packet and 
takes no subsequent action as a direct result of 
having received that packet; the state of the DTE/DCE 
interface as perceived by the DTE remains 
unchanged. In SNA environments, a higher layer is 
also informed using the indicated diagnostic code if a 
diagnostic code is specified. 


— DIAGNOSTIC CODES: are specified in the tables, 
where applicable, by the ‘#’ symbol. Appendix H, 
“DTE-Generated Diagnostic Codes” provides a list of 
the diagnostic codes which may be used by IBM SNA 
X.29 DTEs. 
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ADVISE #'‘x’: the DTE discards the received packet 
and reports the occurrence of the condition indicated 
by ‘#’ to a higher layer of SNA; the state of the 
DTE/DCE interface, as perceived by the DTE, remains 
unchanged. If operating in a DTE/DTE environment, 
the DTE should also send a DIAGNOSTIC packet if 
implemented. 


NORMAL or ERROR: the corresponding action is 
specified following each table. 


STATE TRANSITIONS: are specified in the tables, 
where applicable, by the (li) notation; where ‘I’ is a 
lower case letter and ‘i’ is a numeric variable which 
together identify the resulting state, if any. 


¢« The tables are arranged in order of priority with Table I-1 having 
the highest priority and subsequent tables having lower priority. 
Priority means that when a state belonging to a higher order table 
is specified, that table becomes the applicabl? table. 


In some DTE implementations, certain states (e.g., r3, p7, d3 and. 
j2) may be transient {i.e., the Packet Layer entering one of the 
states as a result of an incoming packet will leave the state by 
generating the prescribed response before processing any subse- 
quent incoming packet). The reactions to incoming packets given 
in these Packet Layer State tables do not apply to states that are 
implemented as transient since such events cannot occur. 


1.2 DTE State/Action Tables 


TABLE I_1: Actions Taken by the DTE Upon Receipt of Packets in Any State 


of the Packet Layer DTE/DCE Interface as Perceived by the DTE 
for SPECIAL SITUATIONS 


Packet Received by the DTE Any State 
Length < 2 octets (including correctly received 
I frames containing no packet information) ADVISE #166 


Packet with Invalid General Format Identifier (GFI) 
(i.e., 7= x'l, 2, 5, 6, 9, A, D or E') 


Packet with Unassigned LCID 


ADVISE #168 


ADVISE #164 


DIAGNOSTIC Packet Received ADVISE #165 


Any packet with a valid GFI and an assigned LCID “See Table 


Figure 
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(including an LCID = x'000') 12 


. DTE Actions tn Special Situations 


++te+ttet¢ttet¢t+¢¢tgte¢tgsss+ 
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With reference to Table [_1: 


Note: IBM SNA X.25 DTEs also report the contents of the Diagnostic code 


and Explanation fields to a higher layer. 


Table I_2: Actions Taken by DTEs Upon Receipt of Packets in Restart-Related 
States of the Packet Layer DTE/DCE Interface as Perceived by the 


DTE 
a ee 


State Packet 


a ee 
Unidentifiable Packet with LCID = x'Q000' 


ADVISE | DISCARD | ERROR 
(r2) 
#169 #169 


(Note 2) with LCID = x'e000' 


#229 #229 


Undefined or Not Supported Packet 
(Note 2) with LCID not = x'@000' 


DISCARD 


#170 


| RESTART INDICATION, RESTART CONFIRMATION, DISCARD | 
or Registration (if supported) with I3 (r2) 


LCID not = ‘000° #226 


ADVISE ERROR DISCARD 
#166, 167) #166, 167 |#166, 167 
or 237 or 237 or 237 


RESTART INDICATION or RESTART CONFIRMATION 
with a format error (Note 1) 


RESTART INDICATION NORHAL DISCARD 
(pl or dl) 


Note 4 #36 


NORMAL 
(r3) 


DCE RESTART CONFIRMATION NORMAL ERROR 
(pl or dl) (r2) 
Note 4 #19 


ADVISE ERROR 
#166, 167 


or 237 


ERROR 
#166, 167 
ur 237 


REGISTRATION REQUEST or 
REGISTRATION CONFIRMATION packet with a 
format error (Note 8) 


REGISTRATION REQUEST or NORHAL 


NORMAL NORMAL - 
REGISTRATION CONFIRMATION packet 
(Note 6,7) 
Packet, other than a Restart, Registration ADVISE ADVISE ADVISE 
(if supported), or DIAGNOSTIC, supported by 
the DTE with LCID = '000' (Notes 2,3) #164 #164 #164 
Call Setup, Call Clearing, DATA, Interrupt, | See DISCARD 
Flow Control, or Reset packet Table I-3 


Figure 1I-2. DTE Actions in Restart-Related States 
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re og ore eno 
| Unidentifiable Packet with LCID not = x‘'0000' Table i DISCARD ERROR 


(r2) #166, 
167 or 237 


DTE DCE 


Layer RESTART RESTART 
Ready REQUEST | INDICATION 
Packet Received by the DTE (rl) (r2) (r3) 


{ 
13 | (r2) 
| | #169 {| #169 
f er sic (aR SS 
Undefined or Not Supported Packet ADVISE | DISCARD ERROR 


RPnAna nA DAN HH NM 


A mA NM nm | Wm Ninh ~™ 


Mm AD A Mm 


NMnAnNnnA Nn ADAH DN 


ao mAanannnna mM 
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With reference to Table [_2: 
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Notes: 


1 
2 


Formats for RESTART packets are described in section 5.5. 


REJECT or Registration packets are not supported when the DTE 
is not capable of using the Packet_Retransmission Facility or the 
On-line Facility Registration Facility, respectively. If the DTE is 
capable of using the On-line Facility Registration Facility but is 
capable of acting only as an initiator or only as a responder for 
the registration procedure, then a REGISTRATION REQUEST 
packet or a REGISTRATION _CONFIRMATION packet, respectively, 
is not supported. 


. Ifthe REGISTRATION REQUEST packet or 


REGISTRATION CONFIRMATION packet is not supported (see note 
2 above), then the packet is treated as “any packet with LCID 
= ‘000°" and the corresponding action invoked. 


. State (p1) for virtual calls or state (d1) for peruanen virtual cir- 


cuits. 


. Formats for the DIAGNOSTIC packets are described in 5.6. 


. Processing of Registration packets is as indicated except if any of 


the following conditions has occurred: 


e In cases where the DTE only acts as an initiator for the 
registration procedure, a received 
REGISTRATION REQUEST packet is treated as a packet 
not supported. 


e In cases where the DTE only acts as a responder for the 
registration procedure, a received 
REGISTRATION CONFIRMATION paren! is treated as a 
packet not supported. 


e In cases where the DTE can act as a responder for the 
registration procedure, a DTE receiving a 
REGISTRATION REQUEST packet when use of the registra- 
tion procedure has not been agreed to transmit a 
REGISTRATION CONFIRMATION packet with the cause 
“Local Procedure Error”, diagnostic “Packet type not com- 
patible with facility”, and no Registration Field. Otherwise, 
the REGISTRATION REQUEST packet is processed as indi- 
cated. 


e in cases where the DTE can act as an initiator for the reg- 
istration procedure, a DTE receiving a 
REGISTRATION CONFIRMATION packet when an uncon- 
firmed REGISTRATION REQUEST packet is not outstanding 
(including the case where use of the registration proce- 
dure has not been agreed to) discards the packet. Other- 
wise, the REGISTRATION CONFIRMATION packet is 
processed as indicated. 


7. A REGISTRATION REQUEST packet may be received, in a 


DTE/DTE environment, only if the agreement to use the 
On-line_Facility_Registration Facility includes the DTE responding 
to registration-procedure initiation. 


Annan nnnn ™M 


Nn 


When receiving a REGISTRATION REQUEST packet modifying one 
or more of the facilities that can take effect only when all logical 
channels used for Virtual Calls are in state P1 and it is possible to 
make the modification, the DTE invokes the ERROR procedure 
(with cause indicating “DTE Originated” and the diagnostic 
“Registration/Cancellation Confirmed”) if there is one or more 
logical channels assigned to Permanent Virtual Circuits. This 
action ensures that the Permanent Virtual Circuits are reset so 
that all of the negotiated facilities can properly take effect. 


8. Formats for Registration packets are described in 5.7.2 and 7.0. 


NORMAL (ri): 


Actions taken by IBM SNA X.25 DTEs, when no error condition has 
occurred, are as defined in §§ 3.3 and 4.0 and the DTE/DCE inter- 
face enters state (ri). 


ERROR # (r2): 


DTEs discard the received packet, report the error condition to a 
higher layer and transmit a RESTART _REQUEST packet across the 
DTE/DCE interface placing all the logical channels in the 

DTE RESTART REQUEST state (r2). 
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TABLE I_3: Actions Taken by the DTE Upon Receipt of Packets in the Call 


Setup and Clearing Related States of the Packet Layer DTE/DCE 
Interface as Perceived by the DTE 


: PACKET LAYER READY rl 


DATA | CALL | DTE | OCE 

XFER | COLL | CLEAR; CLEAR 
RQST! IND. 

p4 p5 p6 p/ 


| READY 


pl 


Unidentifiable Packet TABLE} ERROR} DISC | ERROR 
| 14 (p6) 
#169 

Undefined or Not Supported ERROR TABLE! ERROR} DISC | ERROR 
| (p6) 14 | (p6) (p6) 
#170 #170 #170 


| 
Restart or Registration (if | ERROR; ERROR; ERROR 


CALL_CONNECTED 


INCOMING CALL 


supported) with  (p6) (p6) | (p6) | 14 | (p63 
LCID -= x'0900' | 2226 | #226 | #226 | : aa 


| 


NORMAL NORMAL) ERROR} ERROR) ERROR} DISC 
| (p3) | (p5) | (p6) | (p6) | (p6) | (p6) | (p6) 
: Notes; Notes! #22 #23 #24 z 


| 

TABLE} ERROR! DISC | ERROR | 
- 
| 


Pye 2) ee 


ERROR| NORMAL! ERROR| ERROR: NORMAL} DISC 


(Note 2) | (p6) | (p4) | (p6) | (p6) |(p4)or) (p6) | (P6) 
| #20 | or | #22 | #23 | ERROR #26 
| ERROR (p6) 
| (p6) Notes 
| Note 4 


4,5 


CLEAR_INDICATION NORMAL | NORMAL | NORMAL | NORHAL|NORMAL|NORMAL! DISC 
(Note 2) (p7) | (p7) | (p7) | (p7) | (p7) | (pl) 


DCE _CLEAR_CONFIRNATION 


ERROR | ERROR] ERROR} ERROR] ERROR|NORMAL| ERROR 
(Note 2) (p6) | (p6) | (p6) | (p6) | (p6) | (pl) | (pS) 
#20 #21 | #22 | #23 | #24 #26 


OTHER PACKETS ERROR] ERROR! ERROR| TABLE] ERROR| DISC | ERROR 
(p6) | (p6) | (pé6) 1.4 | (p6) (p6) 
#20 | #21 | #22 #24 #26 


Figure 1-3. DTE Actions in Call Setup and Clearing States 


With reference to Table [_3: 
Notes: 


1. For one-way outgoing logical channels, DTEs transmit 
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CLEAR REQUEST with the diagnostic code #227 on SNA-to-SNA 
connections. 


2. If the packet is acceptable to the state of the logical channel (i.e., 


NORMAL) but contains a format error or is otherwise unaccept- 
able, then the DTE will invoke the ERROR procedure. Formats for 
Call Setup and Call Clearing packets are described in 5.2; formats 
for facility information are described in 7. In addition to being 
properly formatted, address information must contain the correct 
number of digits and specify a valid address. A facility code that 
is not supported or that does noi apply to a DTE/DTE environment 
may be ignored or treated as an error. If the DTE chooses to treat 


Om Mm Ahm HA HM 


A # 


this situation as an error, then it invokes the ERROR procedure 
(with diagnostic “Facility/registration not allowed”). 


3. If the INCOMING CALL packet contains a format error or is other- 
wise unacceptable, then 


e in a DTE/DTE environment, if the DTE is acting as a DCE 
for the purpose of resolving call collisions (see 4.1.6), it 
Shall act as in Note 2. 


e otherwise, the DTE may invoke the ERROR procedure. 


Formats for call setup packets are described in 5.2. In 
addition to being properly formatted, address information 
must contain the correct number of digits and specify a 
valid address. A facility code that is not supported or that 
does not apply in a DTE/DTE environment may be ignored 
or treated as unacceptable; in the later case, diagnostic 
code “Facility/registration code not allowed” applies if the 
DTE invokes the error procedure. 


4. The use by the calling DTE of the Fast Select Facility with a 
restriction on the response prohibits the DCE/remote DTE from 
sending a CALL_ CONNECTED packet. 


5. In a DTE/DTE environment, the DTE that acts as a DCE for pur- 
poses of resolving call collisions (see 4.1.6) will invoke the ERROR 
procedure (with diagnostic = “Packet type invalid for state P5”). 


ERROR: 


DTES report an error situation, using the indicated diagnostic 
code, and clear the virtual call or reset the permanent virtual 
circuit by transmitting a CLEAR/RESET REQUEST packet across 
the DTE/DCE interface. Some DTEs may optionally restart the 


DTE/DCE interface by transmitting a RESTART REQUEST packet. 
DISC: 


emma 


The packet is discarded. No state transition occurs. 


NORMAL (pi): 


DTEs process the received packet in accordance with procedures 
defined in Chapter 4, “Procedures for Virtual Circuit Services.” 
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TABLE 14: Actions Taken by the DTE Upon Receipt of Packets in Reset- 
Related States of the Packet Layer DTE/DCE Interface as 
Perceived by the DTE 


DATA TRANSFER p4 


State FLOW DTE DCE 
CONTROL RESET RESET 
READY REQUEST | INDICATION 
Packet Received from the DCE (d1) (d2) (d3) 


Unidentifiable DISCARD 


Undefined or Not Supported DISCARD ERROR 


(d2) 
#170 
| 
| Restart or Registration (if supported) | ERROR DISCARD ; ERROR | 
| with LCID 7= x'@00' | (d2) (d2) : 
| | #226 | #226 | 
RESET INDICATION | NORMAL NORMAL DISCARD 
Note: 'f) | (43) | (1 or p6)| (3) 
#35 
DCE_RESET CONFIRMATION ERROR NORMAL 
(Note 1) (d2) (d1 or p6) 
#27 
REJECT supported but not subscribed to ERROR DISCARD 
(d2) 
#228 
[INTERRUPT] Table DISCARD ERROR 
I-5 (d2) 
#29 
DATA or Flow Control Table DISCARD ERROR 
I-6 (d2) 
#29 


INVALID PACKET TYPE, DISCARD 
QLLC ERROR, PSH ERROR or 


PACKET NOT SUPPORTED 


(d2) | 
See Attachment H for 
Diagnostic Codes 


(d2) 


Figure 1-4. DTE Actions in Data Transfer States 


With reference to Table |_4: 
Note: 


If the packet is acceptable to the state of the logical channel (i. e., 
NORMAL) but contains a format error, then the DTE will invoke the 
ERROR procedure. Formats for Reset packets are described in 
5.4.3. 


ERROR # (di): 


DTEs discard the packet, report the error condition using the # | 
diagnostic code and clear the virtual call or reset the permanent 
virtual circuit by transmitting a CLEAR/RESET REQUEST packet 
across the DTE/DCE interface. 
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+++++ 
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Some DTEs may optionally restart the DTE/DCE interface by trans- 
mitting a RESTART REQUEST packet across the DTE/DCE inter- 


face. 


NORMAL (di): 


Provided none of the following error conditions or special situ- 


ations has occurred, the actions taken by the DTE follow the pro- 


cedures defined in § 4: 


e If the packet exceeds the maximum permitted length, is too 
short, is not octet aligned, see rule 2) in the introduction to this 
appendix, the DTE will invoke the ERROR #39, #38, or #82 pro- 


cedure, respectively. 


e« if the Ps or Pr received is not valid, the DTE will invoke the 


ERROR #1 or #2 procedure, respectively. 


¢ The DTE will consider the receipt of a DCE_INTERRUPT or 


DCE_INTERRUPT CONFIRMATION packet on an SNA-to-SNA 


connection as an error and will invoke the ERROR #170. 


Table I_5: Actions taken by DTEs on receipt of packets in Interrupt-Related States of the 


Packet Layer DTE/DCE Interface as Perceived by the DTE 


DTE DTE DCE 


INTERRUPT | INTERRUPT | INTERRUPT 


| READY SENT READY 


Packet Received from DCE (ily (iZ) (ji) 


INTERRUPT NORHAL NORMAL NORMAL 
(Note 1) (j2) 


INTERRUPT CONFIRMATION NORMAL NORMAL 
(Note 1) (i1) 


Figure 1-5. DTE Actions in Interrupt States 


With reference to Table [_5: 
Note: 


DCE 
INTERRUPT 
SENT 
(j2) 
ERROR 

(d2) 
#44 


NORMAL 


If the packet is acceptable relative to the state of the logical 
channel (i. e., NORMAL) but contains a format error, then the DTE 
will invoke the ERROR procedure. Formats for Interrupt packets 
are described in 5.3.2 and 5.3.3. 


ERROR # (ilji): 


the DTE discards the received packet and initiates a resetting pro- 
cedure by transferring a RESET REQUEST packet across the 
DTE/DCE Interface for the logical channel specified in the received 
packet and starts Timer T22. The Resetting Cause Field of the 
RESET REQUEST packet should be coded “DTE Originated” and 
the Diagnostic Code field should be coded ‘#’. At this_time, the 
logical channel is in the DTE_Reset_Request state (d2). 
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NORMAL (ilj1): 


If the received packet is acceptable relative to the state of the 
logical channel (i.e., NORMAL) but contains a format error, then 
the DTE will invoke the ERROR procedure (diagnostic codes that 
may apply include #166 or #167). 


Table I_6: Actions Taken by the DTE Upon Receipt of Packets in Flow Control-Related States 
of the Packet Layer DTE/DCE Interface as Perceived by the DTE 


State DCE DCE | DTE DTE 
RECEIVE RECEIVE RECEIVE RECEIVE 
READY NOT READY ~ READY NOT READY 

Packet Received from DCE (f1) (f2) (g1) (g2) 


RR, RNR, or REJECT (if subscribed to) ERROR ERROR ERROR ERROR 
with < 4 octets when using modulo 128 (d2) (d2) (d2) (d2) 
packet sequence numbering #166 #166 #166 #166 

or DISCARD jor DISCARD or DISCARD or DISCARD 

Soi ee an A de are ee eee eS : 


eater re verse er ; i 
| RR, RNR, or REJECT (if subscribed to) ERROR ERROR | ERROR | ERROR 


with an invalid Pr (d2) (d2) | (d2) (d2) 
#2 #2 #2 #2 


ane ee SE ae ee ee 


RR Packet with a Valid Pr NORMAL NORMAL NORMAL NORMAL 
(Note 7) (f1) 
RNR Packet with a Valid Pr NORMAL NORMAL NORMAL NORMAL 
(Note 7) (f2) 
NORMAL NORMAL 


NORMAL 


REJECT (if subscribed to) NORMAL 


with a Valid Pr (Notes 6, 7) 


(f1) 


DATA with < 4 octets when using modulo 128 ERROR 
Packet Sequence Numbering (d2) 
#166 
or DISCARD 


Note 3 


DATA with an Invalid Pr ERROR ERROR 


DATA with a valid Pr and an Invalid Ps or ERROR ERROR 
User Data Field with Improper Format {d2) (d2) 
Note 5 Note 1 
or DISCARD | or DISCARD 
Note 5 Notes 2,3 


DATA with a valid Pr and D=1 when the D-bit ERROR ERROR ERROR 
Procedure is not supported, or M=1 and (d2) (d2) (d2) 
D=O with User Data Field partially full,| Note 2 Note 2 Note 2 
or Q-bit not the same value in al] DATA or DISCARD 


packet of a complete packet sequence (Notes 2,3) 


DATA with a valid Pr, a valid Ps and a NORMAL NORMAL NORMAL DISCARD 
User Data Field with Proper Format Notes 3, 4 


Figure I-6. DTE Actions in Flow Control-Related States 


With reference to Table [_6: 
ERROR # (fiqi): 


the DTE discards the received packet and initiates a resetting pro- 
cedure by transferring a RESET REQUEST packet across the 
DTE/DCE Interface for the logical channel specified in the received 
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packet and starts Timer T22. The Resetting Cause Field of the 
RESET REQUEST packet should be coded “DTE Originated” and 
the Diagnostic Code field should be coded ‘#’. Invoking the 
ERROR procedure, as described above, clears any receive-not- 
ready condition that may exist. 


NORMAL (flgi): 


lf the received packet is acceptable relative to the state of the 
logical channel (i.e., NORMAL) but contains a format error, then 
the DTE will invoke the ERROR procedure (diagnostic codes that 
may apply include #166 or #167). 


Notes: 


a 


The Error procedure may be invoked with the DTE-Originated 
Cause and the appropriate diagnostic code. 


. Although a RNR condition exists at the DTE, the Pr information 


contained in the header of a DATA packet should be proc- 
essed. 


. The DTE may define an internal mechanism to indicate that 


DATA packets have been discarded during a receive-not-ready 
condition. In this case, when the receive-not-ready condition 
clears, one of the recovery mechanisms described in § 4.4 
should be invoked. | 


. In addition to the state transitions resulting from the receipt of 


packets, there may be certain internal stimuli that will cause 
State transitions and the transmission of packets (e.g., local 
receive-not-ready condition detected/cleared resulting in trans- 
mission of a RNR/RR packet). 


Recovery mechanism (b) or (c) described in 3.4.3 may be 
invoked to recover from the receipt of an Invalid Ps or an 
invalid User Data Field. | 


. Receipt of a second REJECT packet before transfer of the 


DATA packet with the Ps equal to the Pr indicated in the pre- 
vious REJECT packet is an error. In this case, the ERROR pro- 
cedure is invoked (with diagnostic “unauthorized reject”). 


. For RR, RNR, or REJECT packets, the presence of one or more 


octets beyond the third octet when modulo 8 numbering ts 
used (or the fourth octet when modulo 128 numbering is used) 
is considered an error. Although a valid Pr may be accepted 
to update the status of outstanding DATA packets, the ERROR 
procedure should be invoked (with diagnostic “Packet too 
long”). Alternatively, the packet may be ignored. 
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Appendix J. Physical Services Headers 


Logical Link Control (LLC) using Physical Services Headers (PSH) 
IBM SNA X.25 DTEs that communicate with remote IBM 5973 Network 


Interface Adapters (NIAs) use the Physical Services Header (PSH) to 
perform the logical link control (LLC) functions described in this appendix. 


J.1 Physical Services Header Formats 


PSHs have the structure depicted in Figure J-1. 


Bits 


8 7 6 5 4 «3 2 1 
Octet |SNA Format Identifier (FID FOX) 
0 ] 1 1 1 SI PSE ot “CPI 
1 PSC or SN or Data 
2 PSC or PSC Modifier (PSXID and PSTEST Information field as 
defined for SDLC XID and TEST, respectively) or Data 
3 : 
ye PSC Modifier or Data | 
n 
Legend: 
R — Reserved | CPI — Control Present Indicator 
(Control = PSC or PSC Modifier 
SI —- Segmenting Indicator 
b'l' — More segments to b'1l' — Control Present 
fol low b'0' — Control Not Present 
b'Q' — Last or only segment 
PSC — Physical Services Command 
PSI — Packet Sequence Indicator 


x'02' = PSDISC (DISCONTACT) 
b'l' — Octet 1 = SN 
— Octet 2 = PSC or Data x'04' = PSXID (EXCHANGE ID) 
b'0' — Octet 1 = PSC or Data x'06' = PSTEST (TEST) 
x'08' = PSCONTACT (CONTACT) 
~ Octet 2 = PSC Modifier 
or Data SN ~ Data Packet Sequence Number 


ul 


Figure J-1. Physical Services Header (PSH): Formats 


Note: Octet 2 of the PSCONTACT and PSTEST responses transmitted by a 
secondary/Remote IBM 5973 NIA contains the SDLC station address. 
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PSHs are inserted in front of SNA PIUs transmitted across the network(s), 


for: 


e Adjacent SNA node physical services - traditional SNA functions 


such as XID, SNRM, and TEST that are mandatory for IBM SNA 
X.25 DTEs. Adjacent SNA node physical services are performed 
according to the same criteria as the equivalent normal response 
mode SDLC functions. 


Data Segmentation - permitting IBM SNA X.25 DTEs to segment 
user data into packets when the ‘M’ bit procedure is not used. 


sequence Numbering - an optional end-to-end packet sequence 
numbering function to provide for the detection of lost, duplicated 
or disordered data packets. 


IBM SNA X.25 DTEs that must remotely connect to an IBM 5973 Network 
Interface Adapter (NIA) that support only PSH LLC must implement QLLC 
with ‘M’ bit segmenting/segment reassembly as well as PSH LLC. 


J.2 Operating Rules 


Rules for use of Physical Services Headers on SNA-to-SNA connections, 


include: 
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e« The first octet of the Call User Data field in call control packets is 


coded with bits 8 through 1 = x‘C2’ or x'C6’ to identify 
SNA-to-SNA connections that use PSHs. 


The PSH is used for segmentation. The ‘M’ bit is not to be set 
equal to ‘1’ by DTEs in data packets when the PSH is used for seg- 
mentation. 


The maximum User Data field length must be the same at both the 
local and remote DTE/DCE interfaces. 


Although either DTE may use the same PSH commands, the use of 
these is asymmetric. One DTE, designated ‘F’, may send PSXID, 
PSTEST or PSCONTACT at any time. The other DTE, designated 
‘R’, must send PSXID, PSTEST or PSCONTACT only after having 
received the corresponding command. 


Either DTE may send PSDISC at any time. 


After sending PSXID, PSTEST or PSCONTACT, ‘F’ waits for a reply 
from ‘R’. There is a timeout associated with this wait. 


If ‘F’ receives a PSXID, PSTEST or PSCONTACT command which is 
not in response to a corresponding command ‘F’ sends PSDISC or 
may terminate the virtual circuit by clearing, resetting or 
restarting. 


When either ‘F’ or ‘R’ receives a PSDISC it responds by sending a 
PSDISC command (unless a PSDISC collision has occurred) or 
else terminates the virtual circuit. 


PSH LLC commands and responses are initiated by the same 
higher-layer events that initiate their SDLC counterparts (see 
Figure 20 in § 8). | 


,J.3 Effects of LAPB Link Resetting 


Resetting of the data link layer re-initializes LAPB sequence numbering 
and constitutes an exposure to the integrity of data, for either direction of 
transmission. Such exposures may be resolved via logical link stations 
using PSH sequence numbering and verification procedures. When data 
integrity errors are detected, PSH stations: 


¢ report link outage(s) to a higher layer of SNA; and, 
¢ remove affected virtual circuit(s) from service by clearing virtual calls 
and resetting permanent virtual circuits. 
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K.1 Implementation Approach 1 


Considerations 


Architectural considerations for SNA-to-non_SNA connections 


Three implementations approaches are defined for SNA-to-non_SNA con- 
nections. In the first one, virtual circuit functions are mapped to an SNA 
session at the SNA boundary node permitting support of non SNA nodes 
across packet-switched networks with limited effect on the subsystems. 
The second approach provides a transparent path between the X.25 
DTE/DCE interface, residing in some SNA boundary node, and an applica- 
tion program interface which handles all the packets defined in CCITT 
Recommendation X.25. The third approach can provide various degrees 
of transparency and mapping for X.25 virtual circuit functions. 


A Packet-Mode DTE implemented in an SNA PU.T4 or PU.T5 node acts as 
a boundary function providing conversion between a virtual circuit and an 
SNA session. The non-SNA remote nodes may establish several virtual 
circuits across the network to/from the SNA PU.T4/T5. To each of these 
virtual circuits, there corresponds a session acting as a transportation 
mechanism towards some application interface in some SNA host node. 


The half session in the PU.T4/T5 will have the appearance of either a SLU 
or a PLU, depending on the direction of call setting. This is to permit 
future extension to the SNA pass through function. 
The following mappings are possible: 
e INCOMING CALL packets may be mapped into either: 
— Request Contact (with a pseudo ID); or, 


— Unformatted INITSELF, carrying the contents of the call user 
data field and the calling DTE address to the USS of an SSCP 
that controls the PU.T4/T5. 


e -+RESP/BIND is mapped into CALL ACCEPTED. 


¢ CONNOUT and BIND provide information to create 
CALL REQUEST. 


e CALL CONNECTED is mapped into +RESP/BIND. 

e CLEAR_INDICATION is mapped into UNBIND. 

e UNBIND is mapped into CLEAR REQUEST. 

° RESET INDICATION is mapped into an extended SNA CLEAR. 
e SNA CLEAR extended is mapped into RESET REQUEST. 

° INTERRUPT is mapped into SIGNAL, and vice versa. 

e The data field of DATA packets are mapped into RUs. 
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e Complete packet sequences need not necessarily be reassembled 
in the PU.T4/T5 before transmission within SNA. Chaining can be 
used within SNA in order to relate unassembled PIUs which 
belong to the same packet sequence. 


¢« No direct mapping can be established between the X.25 window 
rotation mechanism for flow control and the SNA pacing mech- 
anism. The PU.T4/T5 will act as an intermediate buffer and will 
handle flow control on each network as a function of its general 
memory assignment strategy by use of the appropriate mech- 
anism on each side. 


¢ The ‘D’ bit is mapped to the form of RESPONSE REQUESTED bits 
in the RH, where: 


— ‘D’='0' corresponding to the exception response indicator set 
to ‘1’. 
— ‘D'=‘'1' corresponding to the definite response indicator set to 
ra? : 
e Other higher layer SNA functions - such as set and test sequence 
numbers, brackets and function management header protocols - 
are not mappable to X.25. 


K.2 Implementation Approach 2 


A possible architecture to permit transparent handling of X.25 is based on 
the provision of a single session path between the SNA boundary node 
and the application as depicted in Figure K-2 on page K-4. 


All the virtual circuits are multiplexed on this single session flow. Demul- 
tiplexing is performed, by analysis of the logical channel number in the 
packets, by the application. All of the functions of X.25, being thus 
handled transparently to SNA, can be supported in this environment. 


K.3 Implementation Approach 3 


This hybrid approach is a mixture of approaches 1 and 2. Various 
degrees of X.25 transparent and mapped function can be achieved on 
given SNA sessions. 
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Packet—Switched Data Network 


Figure K-1. Virtual Circuit: Relationships to SNA Sessions 
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K-4 


Application 


Program 
Application 
LLLLLTTTTT TTT Program 
Interface 


SNA 
Half Session 


SNA 
Path Control 
Network 


SNA 
Session 


Virtual 
Circuit 


Virtual 
Circuit 


SNA 
Half Session 


SNA X.25 DTE | 


e 


Higher Kio; at Interface Higher 
Level ° Level 
Protocol Protocol 


Packet 
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Appendix L. LAPB SLP Finite State Machines 


The LAPB Single Link Procedure (SLP) described in “Description of the 
LAPB Procedure” on page 2-20 is formalized by the finite state machines 
(FSMs) presented in this appendix. These include: 


-e Table L-1 on page L-6, which specifies the processes, outputs and 
State transitions resulting from stimuli introduced for link con- 
nections perceived to be in one of the seven basic LAPB SLP 
States; 


¢ Table L-2 on page L-10, which specifies the processes, outputs 
and state transitions resulting from stimul! introduced for link con- 
nections perceived to be in the SLP_FSM OPENED state (Informa- 
tion Transfer Phase); and, 


« Table L-3 on page L-16 which specifies the processes, outputs 
and state transitions resulting from stimuli introduced for link con- 
nections perceived to be in the SLP_FSM RECOVER state (Frame 
Rejection Condition). 


L.1 Introduction to Finite State Machines (FSMs) 


A finite state machine is a graphical device that provides a formal 
description of how a mechanism operates It is esnecially useful for illus- 
trating the operational definitions of communication architectures. Finite 
state machines exist in many forms; the following describes how to inter- 
pret the finite state machines used in defining the LAPB SLP architecture. 


Example: Interpreting SLP_FSM 


With reference to Table L-1 on page L-6, assuming state 05, the CLOSING 
state, and the media is inoperative input; the FSM changes to state 01, 
the INOPERATIVE state, and does the process identified by the output 
code ROQ1. Looking below the matrix, in the column OUTPUT CODE, we 
find the letter RO1. Now looking to the right of RO41, in the Function 
column, we find a reference to the procedure to be performed. The pro- 
cedure is Report Status. Refer to the procedure Fteport Status on the indi- 
cated page to see the description of the function to be performed. After 
the procedure, Report Status, is carried out the reader exits from the FSM: 
leaving the FSM in state 01, the INOPERATIVE state. 


Generic Description: How to Interpret a FSM 


To find the actions taken when a specific event takes place, cross- 
reference that input with the current state. At the intersection is an action 


_code, which consists of a next state indicator and an output code. The 


next state indicator is either ‘-’, meaning no state change takes place, ora 
number, which represents the new state. The output code, an alphanu- 
meric identifier, references the output code section located directly after . 
the matrix. Adjacent to the output codes are the functions to be per- 
formed. 
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When a FSM is first activated it is placed in state 01, the initial state; in 
SLP_FSM the initial state is the INOPERATIVE state; in SLP_FSM OPENED 
the initial state is INFO XFER; in SLP_FSM_ CHECK POINT the initial state 
is the CHECKPOINT RECOVER state. 


L.2 LAPB Single Link Procedure 


L.2.1 Events 


Inputs to the SLP FSMs are common and are listed below for easy refer- 
ence and to avoid duplication of information. 


media_is operational - The Media Is Operational event occurs upon a 
transition of the Physical Level to the operational state (see 
§-1.0). 


Start_the link - The Start_The_ Link event represents a higher layer 
(user) request to initialize or restart the SLP (Link Set-up, see 
§-2.4.4.1). : 


stop_the_link- The Stop The Link event represents a higher layer 
(user) request to terminate SLP operation (Link Disconnection, 
see §-2.4.4.3). 


media_is_inoperative - The Media _ Is _ Inoperative event represents a tran- 
sition of the Physical Level to the inoperative state (see §-1.0). 


out_of_resources - The Out_Of Resources event occurs upon detection of 
a station busy condition, as described in §-2.4.5.8, at the local 
Station. 


resources available - The Resources Available event occurs when a 
station busy condition, as described in §-2.4.5.8, is recovered at 
the local station. 


reply_timer_Tp_expired - The Reply Timer Tp Expired event occurs upon 
expiration of Reply Timer, Tp (see §-2.4.8.1) 


query_timer_Tn_expired - The Query_Timer_Tn_Expired event occurs fol- 
lowing a period of link inactivity lasting for the duration of 
Query Timer, Tn (see §§-2.3.4.3, 2.4.5.7 and 2.4.8.8). 


iliegal_frame - The Illegal Frame event occurs upon detection of a Frame 
Rejection Condition as described §§-2.3.4.9 and 2.3.5.4. 


invalid_frame - The Invalid Frame event occurs upon receipt of an invalid 
frames as described in §-2.3.5.3 flags {see §§-2.2.9 and 2.4.2). 


receive_link_channel_is_idle - The Receive _Link_ Channel Is Idle event 
occurs upon expiration of the Idle Time-out period, Ti, as 
described in §-2.2.12.2 (see §-2.4.8.7). 


transmit_link_channel_is ready - The Transmit_Link_Channel_Is Ready 
event occurs following transmission of the last bit of the current 
frame. 


send_data - Represents data received from a higher layer that is to be 
transmitted to the DCE in the information field of an | frame. 
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L.2.2 Commands 


|_ frame_CMD_P_0_inseq - Represents the next in-sequence information 
(1) command frame with the poll (P) bit set to zero, if available, 
(see §-2.4.5.2) otherwise continuous flag sequences. 


|_ frame_CMD_P_0_ack_inseq - Represents the next in-sequence informa- 
tion (1) command frame with the poll (P) bit set to zero, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s), if available, (see §-2.4.5.2) 
otherwise continuous flag sequences. 


| frame_CMD_P_1_inseq - Represents the next in-sequence information 
(I) command frame with the poll (P) bit set to one, if available, 
(see §-2.4.5.2) otherwise continuous flag sequences. 


|_frame_CMD_P_1_ack_inseq - Represents the next in-sequence informa- 
tion (I) command frame with the poll (P) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s), if available, (see §-2.4.5.2) 
otherwise continuous flag sequences. 


| frame_CMD_P_0_out_of_seq - Represents an out-of-sequence informa- 
tion command frame with the poll (P) bit set to zero (see 
§§-2.3.5.2 and 2.4.5.2). 


|_ frame_CMD_P_0_ack_out_of_seq - Represents an out-of-sequence infor- 
mation command frame with the poll (P) bit set to zero, and an 
acknowledgement (an Nr qreater than the last Nr received) for 
previously transmitted I-frame(s), (see §§-2.3.5.2 and 2.4.5.2). 


| frame_CMD_P_1_out_of_seq - Represents an out-of-sequence informa- 
tion command frame with the poll (P) bit set to one (see 
§§-2.3.5.2 and 2.4.5.2). 


| frame_CMD_P_1_ack_out_of_seq - Represents an out-of-sequence infor- 
mation command frame with the poll (P) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame({s), (see §§-2.3.5.2 and 2.4.5.2). 


receive_rdy_frame_CMD_P_0- Represents a Receive Ready (RR) 
command frame with the poll (P) bit set to zero (see §-2.3.4.2). 


receive_rdy_frame_CMD_P_0_ack - Represents a Receive Ready (RR) 
command frame withthe poll (P) bit set to zero, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s), (see §-2.3.4.2). 


receive_rdy_frame_CMD_P_1 - Represents a Receive Ready (RR) 
command frame with the poll (P) bit set to one (see §-2.3.4.2). 


receive_rdy_frame_CMD_P_1_ack - Represents a Receive Ready (RR) 
command frame with the poll (P) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I|-frame(s), (see §-2.3.4.2). 


reject_frame_CMD_P_0- Represents a REJECT (REJ) command frame 
with the poll (P) bit set to zero (see §-2.3.4.4). 
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L.2.3 Responses 


reject_frame_CMD_P_0_ack - Represents a REJECT (REJ) command 
frame with the poll {P) bit set to zero, and an acknowledgement 
(an Nr greater than the last Nr received) for previously trans- 
mitted I-frame(s) (see §-2.3.4.4). 


reject_frame_CMD_P_1 - Represents a REJECT (REJ) command frame 
with the poll (P) bit set to one (see §-2.3.4.4). 


reject_frame_CMD_P_1_ack - Represents a REJECT (REJ) command 
frame with the poll (P) bit set to one, and an acknowledgement 
(an Nr greater than the last Nr received) for previously trans- 
mitted I-frame(s) (see §-2.3.4.4). 


receive_not_rdy_CMD_P_0- Represents a RECEIVE NOT READY (RNR) 
command frame with the poll (P) bit set to zero (see §-2.3.4.3). 


receive_not_rdy_CMD_P_0O_ack - Represents a RECEIVE NOT READY 
(RNR) command frame with the poll (P) bit set to zero, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s) (see §-2.3.4.3). 


receive_not_rdy_CMD_P_1- Represents a RECEIVE NOT READY (RNR) 
command frame with the poll (P) bit set to one (see §-2.3.4.3). 


receive_not_rdy_CMD_P_1_ack - Represents a RECEIVE NOT READY 
(RNR) command frame with the poll (P) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted |-frame(s) (see §-2.3.4.3). 


SABM_frame_CMD_P_0- Represents a SET ASYNCHRONOUS BALANCED 
MODE {(SABM) command frame with the poll (P) bit set to zero 
(see §-2.3.4.5). 


SABM_frame_CMD_P_1- Represents a SET ASYNCHRONOUS BALANCED 
MODE (SABM) command frame with the poll (P) bit set to one 
(see §-2.3.4.5). 


‘ 


disconnect_frame_CMD_P_0 - Represents a DISCONNECT (DISC) 
command frame with the poll (P) bit set to zero (see §-2.3.4.6). 


disconnect_frame_CMD_P_1- Represents a DISCONNECT (DISC) 
command frame with the poll (P) bit set to one (see §-2.3.4.6). 


receive_rdy_frame_RSP_F_0- Represents a RECEIVE READY (RR) 
response frame with the final (F) bit set to zero (see §-2.3.4.2). 


receive_rdy_frame_RSP_F_0_ack - Represents a RECEIVE READY (RR) 
response frame with the final (F) bit set to zero, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s) (see §-2.3.4.2). 


receive_rdy_frame_RSP_F_1- Represents a RECEIVE READY (RR) 
response frame with the final (F) bit set to one (see §-2.3:4.2). 


receive_rdy_frame_RSP_F_1_ack - Represents a RECEIVE READY (RR) 
response frame with the final (F) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted !-frame({s), (see §-2.3.4.2). 


L-4 Architecture Reference 


reject_frame_RSP_F_0- Represents a REJECT (REJ) response frame with 
the final (F) bit set to zero (see §-2.3.4.4). 


reject_frame_RSP_F_0_ack - Represents a REJECT (REJ) response frame 
with the final (F) bit set to zero, and an acknowledgement (an 
Nr greater than the last Nr received) for previously transmitted 
l-frame(s), (See §-2.3.4.4). 


reject_frame_RSP_F_1- Represents a REJECT (REJ) response frame with 
the final (F) bit set to one (see §-2.3.4.3). 


reject_frame_RSP_F_1_ack - Represents a REJECT (REJ) response frame 
with the final (F) bit set to one, and an acknowledgement (an Nr 
greater than the last Nr received) for previously transmitted 
l-frame(s), (see §-2.3.4.4). 


receive_not_rdy_ RSP_F_0- Represents a RECEIVE NOT READY (RNR) 
response frame with the final (F) bit set to zero (see §-2.3.4.3). 


receive _not_rdy_RSP_F_0_ack - Represents a RECEIVE NOT READY 
(RNR) response frame with the final (F) bit set to zero, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s), (see §-2.3.4.3). 


receive _not_rdy RSP_F_1- Represents a RECEIVE NOT READY (RNR) 
response frame with the final (F) bit set to one (see §-2.3.4.3). 


receive_not_rdy_RSP_F_1_ack - Represents a RECEIVE NOT READY 
‘RNR} response frame with the final (F) bit set to one, and an 
acknowledgement (an Nr greater than the last Nr received) for 
previously transmitted I-frame(s), (see §-2.3.4.3). 


unumbered_ack_frame_RSP_F_0O- Represents an UNNUMBERED 
ACKNOWLEDGEMENT (UA) response frame with the final (F) bit 
set to zero (see §-2.3.4.7). 


unumbered_ack_frame_RSP_F_1 - Represents an UNNUMBERED 
ACKNOWLEDGEMENT (UA) response frame with the final (F) bit 
set to one {see §-2.3.4.7). 


disconnect_mode_frame_RSP_F_0- Represents a DISCONNECTED MODE 
(DOM) response frame with the final (F) bit set to zero (see 
§-2.3.4.8). 


disconnect_mode_frame_RSP_F_1 - Represents a DISCONNECTED MODE 
(DM) response frame with the final (F) bit set to one (see 
§-2.3.4.8). 


FRMR_frame_RSP - Represents a FRAME REJECT (FRMR) response 
frame with the final (F) bit set to either zero or one (see 
§-2.3.4.9). 
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SLP_FSM 


Table L-1. 
Function: SLP Finite State Machine 
The states of SLP_FSM are as follows : 

1. INOPERATIVE - state (01) is assumed by link stations when the physical layer 
is not operational (See § 1.0). 

2. CLOSED - state (02) represents the Disconnected Phase described in § 2.4.4.4. 

3. OPENING - state (03) represents the Link Setup Procedure described in § 
2.4.4.1. 

4. OPENED - state (04) represents the Information Transfer Phase described in § 
2.4.4.2. 

9. CLOSING - state (05) represents the Disconnection Phase described in § 
2.4.4.3. 

6. CHECK POINT - state (06) is assumed by link stations following transmission 
of an appropriate supervisory command frame with ‘P = 1° prompted by expi- 
ration of Reply Timer, Tp, (See §§ 2.3.5.2(2) and 2.4.5.9). 

7. RECOVERY - state (07) represents the Frame Rejection Condition described in 
§§ 2.3.4.9, 2.3.5.4 and 2.4.6). 

Input: Inputs that are common to this and the other two FSMs are described in “LAPB 


Single Link Procedure” on page L-1. 


When a finite state machine function must change the state of SLP_FSM the fol- 
lowing tnputs are used. 


go_ to INOPERATIVE state 
go to CLOSED state 

go to OPENING state 

go to OPENED state 

go to CLOSING state 
go_to CHECK _POINT state 
go_to RECOVERY state 
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++ 


+++ 


Inputs 


media_is “operational: 
start_the_link 
stop_the_link 
media_is_inoperative 
out_of_resources 
resources_available 
reply_timer_Tp_expired 
query_timer_Tn_expired 
illegal_ frame 
invalid frame 
receive_link_channel_is_idie 
transmit_link_channel_is_ ready 
send data _ _ woe 
|_frame_CMD_P_0_inseq 
i_frame_CMD_P_0_ack_inseq 
|_frame_CMD_P_1_inseq 
|_frame_CMD_P_1_ack_inseq 
|_frame_CMD_P_0_out_of_seq 


|_frame_CMD_P_0_ack_out_of_seq 


!_frame_CMD_P_1_out_of_seq 
|_frame_CMD_P_1_ack_out_of_seq 
receive_rdy_frame_CMD_P_0 
receive_rdy_frame_CMD_P_0_ack 
receive_rdy_frame_CMD_P_1 
receive_rdy_frame_CMD_P_1_ack 
reject_frame_CMD_P_0 
reject_frame_CMD_P_0_ack 
reject_frame_CMD_P_1 
reject_frame_CMD_P_1_ack 
receive_not_rdy_CMD_P_0 
receive_not_rdy_CMD_P_0_ack 
receive_not_rdy_CMD_P_1 
receive_not_rdy_CMD_P_1_ack 
SABM_frame_CMD_P_0 
SABM_frame_CMD_P_14 
disconnect_frame_CMD_P_6 

| disconnect frame CMD P 1 


receive_rdy_frame_RSP_F_0 
receive_rdy_frame_RSP_F_0_ack 
receive_rdy_frame_RSP_F_1 
receive_rdy_frame_RSP_F_1_ack 
reject_frame_RSP_F_0 
reject_frame_RSP_F_0_ack 
reject_frame_RSP_F_1 
reject_frame_RSP_F_1_ack 
receive_not_rdy_RSP_F_0 
receive_not_rdy_RSP_F_0_ack 
receive_not_rdy_RSP_F_1 
receive_not_rdy_RSP_F_1_ack 
unumbered_ack_frame_RSP_F_0 
unumbered_ack_frame_RSP_F_1 
disconnect_mode_frame_RSP_F_9 
disconnect_mode_frame_RSP_F_1 
FRMR_ frame RSP 


go_to_ CLOSED_state 
go_to_OPENING_ state 
go_to_ OPENED state 
go_to_ CLOSING. state 
go_to_CHECK_POINT_state 


2(NO1) 


inoper- 
ative 


go_to_INOPERATIVE _state 


States 


closed opening opened 


-{FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-{FSMO) 
-{FSMO) 
-(FSMO) 
-(FSMO) 
-{FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-fESMO} 


-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO} 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
| -(FSMO) 
|_-{FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 
-(FSMO) 


0: 10 R ECOV ER Vo SUC Ed 


ae 


_tFSMC 


SLP_FSM 


point pera 


-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 


-{FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-{FSMC) 
-{FSMC) 


-(FSMC} 


ee ee 


(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 
-(FSMC) 4(R18A) 
-(FSMC) 4(R18A) 
-(FSMC) 2(RO8) 
2{RO8) 


-(FSMC) 
-(FSMC) 
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++4+4+4+ 


SLP_FSM 


Output Function 
Code | 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 

Send Frame Reject Response Frame With F equal value of 
P bit in the received command. 4 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 

Send Disconnected Mode Response Frame With F equal value of 

P bit in the received command 


A logically erroneous local conditions that may — 
be reported to a higher layer. 


FSMO See “SLP_FSM_ OPENED” in Table L-2 on page L-9. 
FSMC See “SLP_FSM_CHECK_POINT” in Table L-3 on page L-15. 


ignore the received frame (see §§ 2.2.9, 2.3.5.3, 2.4). 


If the received frame is a command with P = 1, 
Send Disconnected Mode frame with F = 1 Otherwise 
Ignore the received frame 


FO1 
FO2 

FO3 If the received frame is a command, : 

| Send Frame Reject Response Frame With F equal value of 
P bit in the received command Otherwise 
Ignore the received frame 

If transmission limit is exceeded then (see § 2.4.8.1} 

LO4 

NO1 Send continous flag sequence to indicate output link channel is active. 

NOS 

PO1 

RO1 

RO2 

RO? 

RO8 


Inform higher layer 

Go to CLOSED state Else 

Increment transmission count (see § 2.4.8.4). 

send Set Asynchronous Balanced Mode Command Frame With P=1. 


If transmission limit is exceeded then (see § 2.4.8.1) 
Inform higher layer | 

Go to CLOSED state Else 

Increment transmission count (see § 2.4.8.4). - 
send Disconnect Command Frame With P=1 


Initiate the link disconnection procedure (see § 2.4.4.3). 
send Disconnect Command Frame With P=1 


Set-up (initialize) the link in accordance with 
described procedures (see § 2.4.4.1). 
Send Set Asynchronous Balanced Mode Command Frame With P=1. 


Send Disconnected Mode Response Frame With F equal value of 
P bit in the received command 


If transmission limit is exceeded then 
Send Set Asynchronous Balanced Mode Command Frame With P=1. 
Go to OPENING state Else 
Send Frame Reject Response Frame With F equal value of 
P bit in the received command. 


Report Status (as described on page L-21). 


send Set Asynchronous Balanced Mode Command Frame With P= 1. 


Report Status (as described on page L-21). 
send Disconnected Mode Response Frame With F equal the value of the 
P bit in the received command. 


Report Status (as described on page L-21). 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 
P bit in the received command. 
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SLP_FSM 


Function 


Report Status (as described on page L-21). If Enabled and Prepared (as described on page L-22). 
Then 
Set send and receive state variables to 0. 
Send Unnumbered Acknowledgement Response Frame With F equai the value of the 
P bit in the received command. 
Go to OPENED state. See Table L-1 on page L-5. 
Else : 
Send Disconnected Mode Response Frame With F equal the value of the 
P bit in the received command. 


Report Status (as described on page L-21). 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 
5 P bit in the received command. Set send and receive state variables to 0. 


Report Status (as described on page L-21). 
+ ‘Send Set Asynchronous Balanced Mode Command Frame With P=1. 


Start reply timer, Tp, if it is not already running (see § 2.4.8). 
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SLP_FSM_opened 
Table L-2. 


Function: | SLP_FSM_opened Finite State Machine 


The states of SLP_FSM OPENED are as follows: 


. INFO XFER - state (01) represents the Information Transfer Phase described in 


§ 2.4.4.2. 


. REJECT - state (02) represents the Rejection Condition described in §§ 2.3.5.2 


and 2.4.5.6. 


LOCAL BUSY - State (03) represents a Busy Condition, as described in §§ 


2.3.5.1 and 2.4.5.8, at the local station. 


. REMOTE_BUSY - state (04) represents a Busy Condition, as described in §§ 


2.3.9.1 and 2.4.5.8, at the remote station. 


. BOTH_BUSY - state (05) represents a Busy Condition, as described in §§ 


2.3.5.1 and 2.4.5.8, at both the local and remote stations. 


. REJECT AND _LBUSY - state (06) is a composite of the REJECT state (2) and 


the LOCAL BUSY state (3) (see §§ 2.3.5.1, 2.3.5.2, 2.4.5.6, 2.4.5.8). 


REJECT AND RBUSY - state (07) is a composite of the REJECT state (2) and 


the REMOTE BUSY state (4) (see §§ 2.3.5.1, 2.3.5.2, 2.4.5.6, 2.4.5.8). 


. REJECT AND BBUSY - state (08) is a composite of the REJECT state (2) and 


the BOTH_BUSY state (5) (see §§ 2.3.5.1, 2.3.5.2, 2.4.5.6, 2.4.5.8). 


Input: Inputs that are common to this and the other two SLP FSMs are described in 
“LAPB Single Link Procedure” on page L-2. 


When a finite state machine must change the state of SLP_FSM_ OPENED the fol- | 
lowing inputs are used. 


go_to INFO XFER state 

go_to_ REJECT state 

go to LOCAL BUSY state 

go_to REMOTE BUSY state 

go to BOTH BUSY state 

go_to REJECT AND LBUSY state 
go_to REJECT AND_RBUSY_ state 
go to REJECT AND BBUSY state 
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A 


media_is_operational 
start_the_link 
stop_the_link 
media_is_inoperative 
out_of_resources 
resources_available 
reply_timer_Tp_expired 
query_timer_Tn_expired 
iitegal_ frame 

invalid_frame 
receive_link_channel_is_idle 
transmit_link_channel_is_ready 
send data 
|_frame_CMD_P_0_inseq 
|_frame_CMD_P_0_ack_inseq 
|_frame_CMD_P_1_inseq 
|_frame_CMD_P_1_ack_inseq 
|_frame_CMD_P_0_out_of_seq 
|_frame_CMD_P_0_ack_out_of_seq 
|_frame_CMD_P_1_out_of_seq 
|_frame_CMD_P_1_ack_out_of_seq 
receive_rdy_frame_CMD_P_0 
receive_rdy_frame_CMD_P_0_ack 
receive_rdy_frame_CMD_P_1 
receive_rdy_frame_CMD_P_1_ack 
reject_frame_CMD_P_0 
reject_frame_CMD_P_0_ack 
reject_frame_CMD_P_1 
reject_frame_CMD_P_1_ack 
receive_not_rdy_CMD_P_0 
receive_not_rdy_CMD_P_0_ack 
receive_not_rdy_CMD_P_1 
receive_not_rdy_CMD_P_1_ack 
SABM_frame_CMD_P_0 
SABM_frame_CMD_P_1 
disconnect_frame_CMD_P_ 
disconnect frame CMD_P 


0 
1 
receive_rdy_frame_RSP_F_0 
receive_rdy_frame_RSP_F_0_ack 
receive_rdy_frame_RSP_F_1 
receive_rdy_frame_RSP_F_1_ack 
reject_frame_RSP_F_0 
reject_frame_RSP_F_0_ack 
reject_frame_RSP_F_1 
reject_frame_RSP_F_1_ack 
receive_not_rdy_RS 
receive_not_rdy_RS 
receive_not_rdy_RSP_ 
receive_not_rdy_RSP_F_1_ack 
unumbered_ack_frame_RSP_F_0 
unumbered_ack_frame_RSP_F_1 
disconnect_mode_frame_RSP_F_ 
disconnect_mode_frame_RSP_F_ 
FRMR frame RSP F 0 1 
go_to_INFO_XFER_state 
go_to_REJECT_ state 
go_to_ LOCAL _BUSY_state 
go_to_REMOTE_BUSY_ state 

go_to BOTH_BUSY_ state 
go_to_REJECT_AND_LBUSY_ state 
go_to_REJECT_AND_RBUSY_ state 


++ 


++ 


P_F_0 
P_F_0_ack 
Pl 


0 
1 


+++++++ 


ION OO F&F Wh! 


go to REJECT AND BBUSY state 


4{NOGA) 
4{A17A) 
-(R18A) 
-(R18A) 
-(RO8A) 
-(RO8A 


1(LO3A) 
1{RO1A) 
6(R13) 
-(E01) 
1(103A) 
-(E01) 


1{KO4) 
1{A31) 
1(K02) 
1(A02) 
-(D11) 
-(A37) 
-(DO5) 
-(A10) 
-(X13) 
-(A32) 
-{NO6) 
-(A17) 
-($03) 
-(A27) 
-($05) 
-(A29) 
7(NO2) 
7(A15) 
7(NO6A) 
7(A17A) 
1(R18A) 
1(R18A) 
1{RO8A) 


_1f{RO8A) 


-(X13) 
-(A32) 
1(R12A) 
1(R12A) 
-($03) 
-(A27) 
1(R12A) 
1(R12A) 
7(N02) 
7(A15) 
1(R12A) 
1(R12A) 
1(R12A) 
1{R12A) 
1(R12A) 
1(R12A) 


1{L03A) 
1(RO1A) 
-(E01) 
-(R14A) 
1(104D) 
-(E01) 


5(NO7A} 
5(A19A) 
1(R18A) 
1(R18A) 
1(RO8A) 
1(ROBA 
-(X13) 

-(432) 

1(R12A) 


1{R12A) 


-($03) 
-(A27) 
1(R12A) 
1(R12A) 
5(NO2) 
5(A15) 
1(R12A) 
1(R12A) 
1{R12A) 
1(R12A) 
1(R12A)} 
1(R12A) 
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remote 
busy 


-(E01) 
1{LO3A) 
1(RO1A) 
5(R13) 

-(E01) 

1(103B) 
1{LO1C) 


1{R18A) 
1(R18A) 
1(ROBA) 
1{ROBA 
1(NO9) 
1(A32) 
1(R12A) 
1{R12A) 
1($03) 
1(A27) 
1{R12A) 
1(R12A) 
-(NO2) 
-(A15) 
1{R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 


1(RO1A) 
-(E01) 
4{R14) 
1(104A) 
1(L02B) 


S{AT) 
3(S03) 
3{A27) 
3(S06) 
3(A30) 
-(NO2) 
-(A15) 
-(NO7A) 
-(A19A) 
1(R18A) 
1{R18A) 
1(ROBA) 
1(ROBA) 
3(NOQ) 
3(A32) 
1(R12A) 
1(R12A) 
3(S03) 
3(A27) 
1{R12A) 
1(R12A) 
-(NO2) 
-{A15) 
1(R12A) 
1({R12A) 
1{R12A) 
1{R12A) 
1(R12A) 
1(R12A) 


SLP_FSM_opened 


reject 
and 
Ibusy 


-(E01) 
1(LO3A) 
1{RO1A) 
-(E01) 
2{RO3) 
1(104B) 
-(E01) 


1(RO8A) 
1(ROBA 


1(R12A) 
1(R12A) 


-(E01} ‘ 


reject 
and 
rbusy 


-(E01) 
-(E01) 
1(LO3A) 
1(RO1A) 
8(R13) 
-({E01) 
1{103C) 
1(L01) 


217) 
2(S03) 
2{A27) 
2{S05) 
2{A29) 
-(NO2) 
-(A15) 
-(NO6A) 
-(A17A) 
1(R18A) 
1(R18A) 
1{RO8A) 


1(ROBA) 


2{NO9) 
2(A32) 
1(R12A) 
1(R12A) 
(S03) 
2(A27) 
1(R12A) 
1(R12A) 
-(NO2) 
-(A15) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 


Oar wh - ik 


_ 1{RO8A 


5(D02) 
5{A05) 
5{D02) 
5(A05) 
-(DO2} 
-(A05) 
-(DO2) 
-(A05) 
6(NOQ) 
6(A32) 
6(NO7) 
6(AI9) 
6(S03) 
6(A27) 
6(S06) 
6(A30) 
-(NO2) 
-(A15) 
-(NO7A) 
-(A19A) 
1(R18A) 
1({R18A) 
1(RO8A) 


6(X09) 
6(A32) 
1(R12A) 
1(R12A) 
6(S03) 
6(A27) 
1(R12A) 
1(R12A) 
-(NO2) 
-(A15) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1{R12A) 
R12A 
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DP 
Oo 
ns 


AOS 


A08 


A10 


A15 


Alt 


Alva 


A19 


A19A 


A27 
A29 
A30 
A31 
A32 
A37 


A39 
DO2 


DOS 


DO? 


E01 


FO1 


Function 


Advance Transmit Window, Acknowledge Receipt and Forward (as described on page L-20). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window and Discard Frame (as described on page L-20). 


Send Receive Not Ready Response Frame With F equal value of P bit 
in the received frame. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window and Discard Frame (as described on page L-20). 
Send Reject Response Frame With F equal value of P bit in the received frame. Reset Reply Timer Tp (as 
described on page L-21). 


Advance Transmit Window and Discard Frame (as described on page L-20). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window (as described on page L-20). Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn 


Advance Transmit Window (as described on page L-20). 
Send Receive Ready Response Frame With F=1. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window (as described on page L-20). 
Send Receivé Ready Response Frame With F=1. Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn. 


Advance Transmit Window (as described on page L-20). 


eeeancnistavesenemenneimstsomerenitnrai etnies etter Hee moatin aan spn mere anh rere 


Advance Transmit Window (as described on page L-20). 
Send Receive Not Ready Response Frame With F=1. Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn. 


Advance Transmit Window and Set Send Sequence (as described on page L-20). Invoke Output UPM 


reer arrest amie renner nan mney tr at henna nem esa NCR re RE AT 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 
Send Receive Ready Response Frame With F=1. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 
Send Receive Not Ready Response Frame With F=1. Reset Reply Timer Tp (as described on page L-21). 


Advance Transmit Window, Acknowledge Receipt and Forward (as described on page L-20). Invoke Output 
UPM (acknowledgement) (as described on page L-21). 
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Advance Transmit Window (as described on page L-20). Invoke Output UPM (acknowledgement) (as 
described on page L-21). 
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described on page L-21). 
Invoke Output UPM (data) (as described on page L-21). 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 

Send Receive Not Ready Response Frame With F equal value of P bit 
in the received frame. 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 
Send Receive Ready Response Frame With F equal vaiue of P bit in the 
received frame. 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 
Send Reject Response Frame With F equal value of P bit in the received frame. 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). Invoke Output UPM (null) (as described on page L-21). 


A logically erroneous local conditions that may 
be reported to a higher layer. 


Ignore the received frame (see §§ 2.2.9, 2.3.5.3, 2.4). 
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+++ 


+++ 


+++ 


+++ 


+++4 


+++ 


+++ 


SLP_FSM_opened 


Output Function 
Code 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK POINT state. See Table L-1 on page L-5. 
Change SLP_FSM CHECK POINT to RECOVER _AND_ REJECT state. See Table L-3 on page L-15. 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_ CHECK POINT to RECOVER _AND_RBUSY state. See Table L-3 on page L-15. 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK _POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_CHECK_POINT to RECOVER REJECT RBUSY state. See Table L-3 on page L-15. 


l03D If retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-S. 
Change SLP_FSM_CHECK_ POINT to CHECK_POINT_RECOVERY state. See Table L-3 on page L-15. 
lO4A lf retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_CHECK_POINT to RECOVER_AND_BBUSY state. See Table L-3 on page L-15. 


lf retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_CHECK_POINT to RECOVER_REJECT_LBUSY state. See Table L-3 on page L-15. 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count. (see § 2.4.8.4). 
Send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-S. 
Change SLP_FSM CHECK POINT to RECOVER_REJECT BBUSY state. See Table L-3 on page L-15. 
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+++ 


SLP_FSM_opened 


Output Function 
Code 


104D If retry limit is exceeded then 
Report Status (as described on page L-21). 
send Set Asynchronous Balanced Mode Command Frame with P = 1. 
Change SLP_FSM to OPENING state. Else 
Increment transmission count (see § 2.4.8.4). 
Send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_ CHECK POINT to RECOVER_AND_LBUSY state. See Table L-3 on page L-15. 


A 
O 
nm 


Acknowledge receipt (increment Vr by ‘1’) of the received frame and 
pass the information field to a higher layer (see § 2.4.5.2(1)). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. ; 


K04 Acknowledge receipt (increment Vr by ‘1’) of the received frame and 
pass the information field to a higher layer (see § 2.4.5.2(1)). Invoke Output UPM (acknowledgement) 


(as described on page L-21). 


LO1 


Assure link operation by transmitting a command frame with P=1 and 
starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 

Send Receive Ready Command Frame With P=1. 

Initialize poll count. (see § 2.4.5.9). 

Change SLP_FSM to CHECK POINT state. See Table L-1 on page L-S. 

Change SLP_FSM CHECK POINT to RECOVER_REJECT_BBUSY state. See Table L-3 on page L-15. 


Assure link operation by transmitting a command frame with P=1 and 
Starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 

Send Receive Ready Command Frame With P=1. 

Initialize poll count. (see § 2.4.5.9). 

Change SLP_FSM to CHECK POINT state. See Table L-1 on page L-S. 

Change SLP_FSM_CHECK_POINT to RECOVER_AND_RBUSY state. See Table L-3 on page L-15. 


LOIC 


LO2 Assure link operation by transmitting a command frame with P=1 and 
starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 
Send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-5. 
Change SLP_FSM_ CHECK_POINT to RECOVER_REJECT_BBUSY state. See Table L-3 on page L-15. 
LO2B Assure link operation by transmitting a command frame with P=1 and 


starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 
Send Receive Not Ready Command Frame With P=1. 
Initialize poll count. (see § 2.4.5.9). : 
Change SLP_FSM to CHECK_POINT state. See Table L-1 on page L-S. 
Change SLP_FSM_CHECK_ POINT to RECOVER_AND_BBUSY state. See Table L-3 on page L-15. 


LO3A Initiate the link disconnection procedure (see § 2.4.4.3). 
send Disconnect Command Frame With P=1 
Change SLP_FSM to CLOSING state. See Table L-1 on page L-S5. 


Start Timer Tn 


send Receive Ready Response Frame With F=1. 


NO2 
NO6 
Send, Receive Ready Response Frame With F=1. 
Start Timer Tn. 
NO7 


Send Receive Not Ready Response Frame With F=1. 


NO7A Send Receive Not Ready Response Frame With F=1. 
Start Timer Tn. 
Nog Invoke Output UPM (null) (as described on page L-21). 
RO1A Report Status (as described on page L-21). Change SLP_FSM to INOPERATIVE state. See Table L-1 on 
page L-S5. 
RO3 Report Status (as described on page L-21). 


Send Receive Ready Response Frame With F=0. 
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SLP_FSM_opened 


Output Function 
Code 


ROS Report Status (as described on page L-21). 
Send Frame Reject Response Frame With F equal value of 
P bit in the received command. 
+ Start Timer T1 
Change SLP_FSM to RECOVERY state. 


RO6 Report Status (as described on page L-21). 
See “Detection of the Idle Channel Condition” on page L-20. 


RO8A Report Status (as described on page L-21). 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 


P bit in the received command. Change SLP_FSM to CLOSED state. See Table L-1 on page L-S. 


R12A Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. 


Change SLP_FSM to OPENING state 


+++ 


R13 Report Status (as described on page L-21). If Response to Command Required (see page L-22). 
Then . 
Send Receive Not Ready Response Frame With F=1. 
Else 
If Convenient Response Opportunity (as described on page L-22). 
Then 
Send Receive Not Ready Response Frame With F=0. 
R14 Report Status (as described on page L-21). If Convenient Response Opportunity then (as described on page 
L-22). 
lf information field(s) have been discarded then 
Send Reject Response Frame With F =O. 
Go to REJECT AND _RBUSY state 
Else 
Send Receive Ready Response Frame With F=Q. Else 
lf information field(s) have been discarded then 
Send Reject Command Frame With P =0. 
Go to REJECT AND RBUSY state 
Else 
Send Receive Ready Command Frame With P =0. 
R14A Report Status (as described on page L-21). If Convenient Response Opportunity then (as described on page 


L-22). 
If information field(s) have been discarded then 
Send Reject Response Frame With F=O. 
Go to REJECT state. See Table L-2 on page L-9. 
Else 
Send Receive Ready Response Frame With F=0. 
Go to INFO_XFER state. See Table L-2 on page L-9. Else 
If information field(s) have been discarded then 
Send Reject Command Frame With P =0. 
Go to REJECT state. See Table L-2 on page L-9. 
Else 
Send Receive Ready Command Frame With P =0. 
Go to INFO_XFER state. See Table L-2 on page L-9. 


R18A Report Status (as described on page L-21). 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 
P bit in the received command. Set send and receive state variables to 0. 


+- 


503 Set Send Sequence (as described on page L-21). Invoke Output UPM (null) (as described on page L-21). 


S05 Set Send Sequence (as described on page L-21). 
Send Receive Ready Response Frame With F=1. 


S06 Set Send Sequence (as described on page L-21). 
send Receive Not Ready Response Frame With F=1. 


X13 Ignore this input. 
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SLP_FSM_check_point 


Table L-3. 
Function: SLP_FSM_check_point Finite State Machine 
The states of SLP_FSM_CHECK_POINT are as follows: 
1. CHECK_POINT_RECOVER - state (01) is entered by link stations upon expiration of 
Reply Timer, Tp, following transmissions of an appropriate Supervisory command 
frame with ‘P = 1’ (see §§ 2.3.5.2(2) and 2.4.5.9). 
2. RECOVER_AND_ REJECT - state (02) is a composite of the CHECK_POINT RECOVER 
state (01) of SLP_FSM CHECK POINT and the REJECT state (02) of SLP_FSM_OPENED. 
3. RECOVER AND LBUSY - state (03) is a composite of the SLP_FSM_ CHECK_POINT 
RECOVER state (01) and the LOCAL_BUSY state (03) of SLP_FSM_OPENED (see §§ 
2.3.9.1, 2.4.5.8 and 2.4.5.9). 
4. RECOVER_AND_RBUSY - state (04) is a composite of the Link Layer 
LAPB_ FSM CHECK POINT RECOVER state (01) and the REMOTE_BUSY state (04) of 
SLP_FSM_ OPENED (see §§ 2.3.5.1, 2.4.5.8 and 2.4.5.9). 
5. RECOVER_AND BBUSY - state (05) is a composite of the SLP_FSM_CHECK_POINT 
RECOVER state (01) and the BOTH_BUSY state (05) of SLP_FSM OPENED (see §§ 
2.3.5.1, 2.4.5.8 and 2.4.5.9). 
6. RECOVER_REJECT_LBUSY - state (06) is a composite of the SLP_FSM_ CHECK_POINT 
RECOVER state (01), the REJECT state (02) of SLP_FSM_ OPENED, and the 
LOCAL_BUSY state (03) of SLP_FSM_OPENED. 
7. RECOVER_REJECT_RBUSY - state (07) is a composite of the SLP_FSM_ CHECK_POINT 
RECOVER state (01), the REJECT state (02) of SLP_FSM_OPENED, and the 
REMOTE _BUSY state (04) of SLP_FSM_OPENED. 
8. RECOVER_REJECT_BBUSY - state (08) is a composite of the 
LAPB FSM CHECK POINT RECOVER state (01), the REJECT state (02) of 
SLP_FSM_ OPENED, and the BOTH_BUSY state (05) of SLP_FSM_OPENED. 
Input: Inputs that are common to this FSM and the other two SLP FSMs are described in “LAPB 


Single Link Procedure” on page L-2. 


When a finite state machine must change the state of SLP_FSM_CHECK_POINT the fol- 
lowing inputs are used. Output codes suffixed by a letter of the alphabet generally use 
these inputs. | 


© go to CHECK _POINT RECOVER 
° go to RECOVER AND REJECT 
° go to RECOVER AND LBUSY 

-* go to RECOVER_AND_RBUSY 
© go to RECOVER _AND_BBUSY 
© go to RECOVER REJECT _LBUSY 
° go to RECOVER REJECT _RBUSY 
© go to RECOVER REJECT BBUSY 
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_disconnect frame CMD 


+t+++4+ 


Inputs 


media_is_operational 
start_the_link 
stop_the_link 
media_is_inoperative 
out_of_resources 
resources _available 
reply_timer_Tp_expired 
query_timer_Tn_expired 
itlegal_ frame 
invalid_frame 


receive_link_channel_is_idle 


transmit_link_channel_is_ready 


send data 
|_frame_CMD_P_0_inseq 


|_frame_CMD_P_0_ack_inseq 


i_frame_CMD_P_1_inseq 


|_frame_CMD_P_1_ack_inseq 
|_frame_CMD_P_0_out_of_seq 


|_frame_CMD_P_0_ack_out_of_seq 


|_frame_CMD_P_1_out_of_seq 


|_frame_CMD_P_1_ack_out_of_seq 


receive_rdy_frame_CMD_P_0 


receive_rdy_frame_CMD_P_0_ack 


receive_rdy_frame_CMD_P_1 


receive _rdy frame_CMD_P_1_ack 


reject_frame_CMD_P_90 


reject_frame_CMD_P_0_ack 


reject_frame_CMD_P_1 


reject_frame_CMD_P_1_ack 


receive_not_rdy_CM 


receive_not_rdy_CM 

receive_not_rdy_CMD_ 
SABM_frame_CMD_P_0 
SABM_frame_CMD_P_1 
disconnect_frame_CMD 


D_P_0 
receive_not_rdy_CMD_P_0 
D_P_1 

P_1 


receive_rdy_frame_RSP_ 


reject_frame_RSP_F_0 


reject_frame_RSP_F_0_ack 


reject_frame_RSP_F_1 


reject_frame_RSP_F_1_ack 


receive_not_rdy_RS 
receive_not_rdy_RS 
receive_not_rdy_RSP_ 


B 
ee 


ae 
P 


1 
receive_rdy_frame_RSP_F_0 
F_0O 


ack 


ack 


0 


receive_rdy_frame_RSP_F_1 - 
receive_rdy_frame_RSP_F_1_ack 


F_0 
F_0_ack 
F_1 


receive_not_rdy_RSP_F_1_ack 


unumbered_ack_frame_RSP_F_0 
unumbered_ack_frame_RSP_F 
disconnect_mode_frame_RSP 
disconnect_mode_frame_RSP 


FRMR frame RSP_F 0 1 


go_to_CHECK_POINT_RECOVER 


go_to_RECOVER_AND_REJECT 
go_to_RECOVER_AND_LBUSY 
go_to_RECOVER_AND_RBUSY 
go_to_RECOVER_AND_BBUSY 


go_to_RECOVER_REJECT_LBUSY 
go_to_RECOVER_REJECT_RBUSY 
go to RECOVER REJECT BBUSY__ 


ack 


_1 
F 
F 


SLP_FSM_check_point 


check 
point 


recover 


4(A15) 


4{NOGA) 
4(A17A) 
-(R18A) 
-(R18A) 
-(RO8A) 
-(ROBA 


41(ROBA 


recover 


1(RO1A) 
6(R13) 
-(E01) 
-(103) 
-(LO1) 
1(R05) 
-(FO1) 
-{R08) 
-(T03) 
(A392) 


7(A15) 

7(NO6A) 
7(A17A) 
1(R18A) 
1(R18A) 
1(RO8A) 


-(X13) 
-(A13) 
1(X07B) 
1{A35B) 
-(S03) 
-(A34) 
1{S08B) 
1({A36B) 
7(X13) 
7(A13) 
1(NO2B) 
1(A24B) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
1 


1{RO8A} 


recover 
and 


1(RO8A) 


-(A13) 
1(X07C) 
1(A35C) 
-($03) 
-(A34) 


1(R12A) 
1{R12A) 
1(R12A) 
1(R12A) 
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1(R18A) 
1(R18A) 
1(RO8A) 
1{ROBA 

1{X13) 


__1{RO8A} 


recover 
and 


1(RO1A) 
-(E01) 
4(R03) 
-(104) 
-(LO2) 


31X13) 
3{A13) 
3iNO7) 
BA 19% 
3{S03) 
3(A27) 
3(S06) 
3(A30) 
-(NO2) 
-(A15) 
-(NO7A) 
-(A19A) 
1(R18A) 
1(R18A) 
1(RO8A) 


3(X13) 
3(A13) 
1{X07C) 
1(A35C) 
3(S03) 
3(A34) 
1(SO08C) 
1(A36C) 


recover 
reject 


1(RO1A) 
-(E01) 
2{RO3) 
-(104) 
-(LO2) 
1(RO5) 
-{FO1) 
-{RO8) 
-(T03) 
-{A39) 
3(D02) 
3(A05) 
3(D02) 
3(A05) 
-(D02) 
-(A05) 
-(D02) 
-(A05) 
-(X13) 
-(A13) 
-{NO7) 
EATON 
-{$03) 
-(A27) 
-(S06) 
-(A30) 
8{NO2) 
8(A15) 
8{NO7A) 
8(A19A) 
1(R18A) 
1(R18A) 
1(RO8A) 
1(RO8A’ 
-(X13) 
-(A13) 
1(X07D) 
1(A35D) 
-(S03) 
-(A34) 


1({S09C) 


1(X08C) 
(X13) 
8(A13) 
1(NO2C) 
1(A24C) 


1{R12A) 


1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 


recover 
reject 


1{RO1A) 
8(R13) 
-{E01) 
-(103) 
-(LO1) 
1{R05) 
-(FO1) 
-(RO6) 
-{T03) 
-£A39) 
4{K02) 
4(A02) 
4{K02) 
4{A02) 
-{(DO5) 
-(A10) 
-(D05) 
-(A10) 
2{X13) 
2{A13) 
2(N08) 


2{A17} 


2{$03) 
2(A27) 
2(S05) 
2{A29) 
-(NO2) 
-(A15) 
-(NO6A) 
(A17A) 
1(R18A) 
1{R18A) 
1(RO8A) 
1(ROBA) 
2(X13) 
2(A13) 
1(X07B) 
1(A35B) 
2($03) 
2(A34) 
1(S08B) 
1(A36B) 
-(X13) 
-(A13) 
1(NO2B) 
1(A24B) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 


recover 
reject 


6(S03) 
6(A27) 
6(S06) 
6(A30) 
-(NO2) 
-(A15) 
-(NO7A) 
-(A19A) 
1(R18A) 
1(R18A) 
1{RO8A) | 
1(RO8A 
6(X13) 
6(A13) 
1(X07D) 
1(A35D) 
8(S03) 
6(A34) 
1(S09C) 
1(X08C) 
-(X13) 
-{A13}) | 
1(NO2C) | 
1{A24C) 
1(R12A) 
1(R12A) 
1(R12A) 
1(R12A) 
{ 
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SLP_FSM_check_point 


Output 


Code 
A02 


AOS 


A08& 


A10 


A13 
A15 
A15A 


A15B 


Al? 


AI7A 


A193 


A19A 


A24B 


A24C 


A27 
A29 
A30 


A34 
A35A 


A35B 
A35C 
A35D 


A36A 


Function 


_ Advance Transmit Window, Acknowledge Receipt and Forward (as described on page L-20). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. . 


Advance Transmit Window and Discard Frame (as described on page L-20). 
Send Receive Not Ready Response Frame With F equal value of P_ bit 
in the received frame. 


Advance Transmit Window and Discard Frame (as described on page L-20). 
Send Reject Response Frame With F equal value of P bit in the received frame. 


Advance Transmit Window and Discard Frame (as described on page L-20). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. . 


Advance Transmit Window (as described on page L-20). 
Advance Transmit Window (as described on page L-20). Start Timer Tn 


Advance Transmit Window (as described on page L-20). Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 
SLP_FSM_ OPENED to REMOTE_BUSY state. See Table L-2 on page L-9. 


Advance Transmit Window (as described on page L-20). Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 
SLP_FSM_OPENED to BOTH _ BUSY State. See Table L-2 on page L-9. 


Advance Transmit Window (as described on page L-20). 
Send Receive Ready Response Frame With F=1. 


eet 


Advance Transmit Window (as described on page L-20). 
Send Receive Ready Response Frame With F=1. Start Timer Tn. 


Advance Transmit Window (as described on page L-20). 
Send Receive Not Ready Response Frame With F=1. 


Advance Transmit Window (as described on page L-20). 
Send Receive Not Ready Response Frame With F=1. Start Timer Tn. 


Advance Transmit Window (as described on page L-20). Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 
SLP_FSM_ OPENED to REJECT _AND_RBUSY state. See Table L-2 on page L-9. 


Advance Transmit Window (as described on page L-20). Reset Reply Timer Tp (as described on page L-21). 
Start Timer Tn Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change | 
SLP_FSM_OPENED to REJECT _AND_ BBUSY state. See Table L-2 on page L-9. 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 
send Receive Ready Response Frame With F=1. . 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 
Send Receive Not Ready Response Frame With F=1. 


Advance Transmit Window and Set Send Sequence (as described on page L-20). 


Advance Transmit Window (as described on page L-20). Invoke Output UPM (null) (as described on page © | 
L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM OPENED to 
INFO_XFER state. See Table L-2 on page L-9. | 


Advance Transmit Window (as described on page L-20). Invoke Output UPM (null) (as described on page 
L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM OPENED to 
REJECT state. See Table L-2 on page L-9. 3 


Advance Transmit Window (as described on page L-20). Invoke Output UPM (null) (as described on page 
L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM OPENED to 
LOCAL BUSY state. See Table L-2 on page L-9. 


Advance Transmit Window (as described on page L-20). Invoke Output UPM (null) (as described on page 
L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM OPENED to > 
REJECT _AND_LBUSY state. See Table L-2 on page L-9. _ 


Advance Transmit Window and Set Send Sequence (as described on page L-20). Invoke Output UPM (null) 
(as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 


SLP_FSM_OPENED to INFO_XFER state. See Table L-2 on page L-9. 
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+++ 


++4 


Output 
Code 
A36B 


A36C 


a39 


DOS 


A 
2) 
NR 


LO1 


Lo2 


NO2A 


NO2B 


NO2C 


SLP_FSM_check_point 


Function 


Advance Transmit Window and Set Send Sequence (as described on page L-20). Invoke Output UPM (nuil) 
(as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 
LAPB_FSM_OPENED to REJECT state. See Table L-2 on page L-9. 


Advance Transmit Window and Set Send Sequence (as described on page L-20). Invoke Output UPM (null) 
(as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change 
SLP_FSM_OPENED to LOCAL_BUSY state. See Table L-2 on page L-9. 


Invoke Output UPM (data) (as described on page L-21). 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 
Send Receive Not Ready Response Frame With F equal value of P bit 


in the received frame. 


Discard the information field contained in 
the received frame (see §§ 2.4.4.4). 
Send Receive Ready Response Frame With F equal value of P bit in the 
received frame. 


Discard the information field contained in 


the received frame (see §§ 2.4.4.4). 
Send Reject Response Frame With F equal value of P bit in the received frame. 


A logically erroneous local conditions that may 
be reported to a higher layer. 


Ignore the received frame (see §§ 2.2.9, 2.3.5.3, 2.4}. 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P 
Change SLP_FSM to OPENING state. 
Go to CHECK_POINT_RECOVER state Else 
Send Receive Ready Command Frame With P= 1. 
Increment poll count. (see § 2.4.5.9). 


i 
—_ 
: 


If retry limit is exceeded then 
Report Status (as described on page L-21). 
Send Set Asynchronous Balanced Mode Command Frame with P 
Change SLP_FSM to OPENING state. 
Go to CHECK_POINT_RECOVER state Else 
Send Receive Not Ready Command Frame With P=1. 
Increment poll count. (see § 2.4.5.9). 


HI 
—_ 
. 


Acknowledge receipt (increment Vr by ‘1’) of the received frame and 
pass the information field to a higher layer (see § 2.4.5.2(1)). 

Send Receive Ready Response Frame With F equal value of P bit in the 

received frame. 


Assure link operation by transmitting a command frame with P=1 and 
starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 
Send Receive Ready Response Frame With F=1. 


Assure link operation by transmitting a command frame with P=1 and 
starting reply timer, Tp (see §§ 2.4.3 and 2.4.5.9). 
send Receive Not Ready Command Frame With P=1. 


Start Timer Tn 


Start Timer Tn Reset Reply Timer Tp (as described on page L-21). Change SLP_FSM to OPENED state. See 
Table L-1 on page L-5. Change SLP_FSM_ OPENED to REMOTE_BUSY state. See Table L-2 on page L-9. 


Start Timer Tn Reset Reply Timer Tp (as described on page L-21). Change SLP_FSM to OPENED state. See 
Table L-1 on page L-5. Change SLP_FSM_OPENED to REJECT AND _RBUSY state. See Table L-2 on 

page L-9. 

Start Timer Tn Reset Reply Timer Tp (as described on page L-21). Change SLP_FSM to OPENED state. See 
Table L-1 on page L-5. Change SLP_FSM_OPENED to REJECT AND BBUSY state. See Table L-2 on 

page L-9. | 


Send Receive Ready Response Frame With F=1. 


Send Receive Ready Response Frame With F=1. Start Timer Tn. 
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+ 
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SLP_FSM_check_point 


Function 


Output 
Code 


NO7 Send Receive Not Ready Response Frame With F=1. 


NO7A Send Receive Not Ready Response Frame With F=1. Start Timer Tn. 


Report Status (as described on page L-21} 
ROIA Report Status (as described on page L-21) Change SLP_FSM to INOPERATIVE state. See Table L-1 on 
page L-S. 
ROS Report Status (as described on page L-21) 


Send Receive Ready Response Frame With F=0. 


ROS Report Status (as described on page L-21) 


Send Frame Reject Response Frame With F equal value of 
P bit in the received command. Change SLP_FSM to RECOVERY state. See Table L-1 on page L-5. 


Report Status (as described on page L-21) See “Detection of the Idle Channel Condition” on page L-20. 


RO8A Report Status (as described on page L-21) 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 
P bit in the received command. Change SLP_FSM to CLOSED state. See Table L-1 on page L-S. 


R12A Report Status (as described on page L-21) 
Send Set Asynchronous Balanced Mode Command Frame with P = 1. Change SLP_FSM to Opening State 
R13 Report Status (as described on page L-21) If Convenient Response Opportunity (as described on page L-22). 
Then 
Send Receive Not Ready Response Frame With F=0. 
Else If Response to Command Required (as described on page L-22). 


Then 
Send Receive Not Ready Response Frame With F=1. 


R18A Report Status (as described on page L-21). 
Send Unnumbered Acknowledgement Response Frame With F equal the value of the 
: P bit in the received command. Change SLP_FSM to OPENED state. See Table L-1 on page L-5. 
S03 Set Send Sequence (as described on page L-21). 
S05 Set Send Sequence (as described on page L-21)}. 


send Receive Ready Response Frame With F=1. 


S06 Set Send Sequence (as described on page L-21). 
Send Receive Not Ready Response Frame With F=1. 


SO8A Set Send Sequence (as described on page L-21). Invoke Output UPM (null) (as described on page L-21). 
Change SLP_FSM to OPENED state. See Table L-1 on page L-5. 


Set Send Sequence (as described on page L-21). Invoke Output UPM (null) (as described on page L-21). 
Change SLP_FSM to OPENED state. See Table L-1 on page L-5S. Change SLP_FSM_OPENED to REJECT 
state. See Table L-2 on page L-9. 


S08B 


Set Send Sequence (as described on page L-21). Invoke Output UPM (null) (as described on page L-21). 
Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM_OPENED to 
LOCAL _BUSY state. See Table L-2 on page L-9. 


S08C 


SO09C Set Send Sequence (as described on page L-21). Invoke Output UPM (null) (as described on page L-21). 
Change SLP_FSM to OPENED state. See Table L-1 on page L-5. Change SLP_FSM_OPENED to 
REJECT AND _LBUSY state. See Table L-2 on page L-9. 


Start reply timer, Tp, if it is not already running (see § 2.4.8). 


X02B Start Timer Tn Reset Reply Timer Tp (as described on page L-21). Change SLP_FSM to OPENED state. See 


Table L-1 on page L-5. Change SLP_FSM_ OPENED to BOTH BUSY state. See Table L-2 on page L-9. 


X07A Invoke Output UPM (null) (as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 
on page L-5. 


X07B Invoke Output UPM (null) (as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 


on page L-5. Change SLP_FSM OPENED to REJECT state. See Table L-2 on page L-9. 


Invoke Output UPM (null) (as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 
On page L-5. Change SLP_FSM_OPENED to LOCAL BUSY state. See Table L-2 on page L-9. 


X07C 


Invoke Output UPM (null) (as described on page L-21). Change SLP_FSM to OPENED state. See Table L-1 
on page L-5. Change SLP_FSM_ OPENED to REJECT _AND_LBUSY state. See Table L-2 on page L-9. 


X07D 


oO 
O 
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SLP_FSM_check_point 


Output 
Code 


X08C Advance Transmit Window and Set Send Sequence (as described on page L-21). Invoke Output UPM (null) 
(as described on page L-22). Change SLP_FSM to OPENED state. See Table L-1 on page L-6. Change 
SLP_FSM OPENED to REJECT _AND_LBUSY state. See Table L-2 on page L-10. 


Ignore this input. 


ADVANCE XMIT_WIN 


FUNCTION: Advance Transmit Window 


Advance the lower transmit window edge to the Nr contained in the 
received frame (see § 2.4.5.5). 


ADVANCE_XMIT_WIN ACK REC_FOR 


FUNCTION: Advance Transmit Window, Acknowledge Receipt and Forward 


Advance the lower transmit window edge to the Nr contained in the 


received frame, acknowledge receipt (increment Vr by ‘1’ .) 
of the received frame and pass the information field to a higher 
layer (see § 2.4.5.9). 


ADVANCE_XMIT_WIN_XET_SND_SEQ 


FUNCTION: Advance Transmit Window and Set Send Sequence 


Advance the lower transmit window edge to the Nr contained in 
the received frame and set the send sequence variable (Vs) 
equal to the value of Nr contained in the received frame 

(see §§ 2.4.5.5 and 2.4.5.6). 


ADVANCE_XMIT_WIN_AND_DISC_FRM 


FUNCTION: Advance Transmit Window and Discard Frame 


Advance the lower transmit window edge to the Nr contained in 
the received frame and discard the information field 
(see §§ 2.4.5.2(2) and 2.4.5.5). 


DETECT IDLE_CHANNEL 


FUNCTION: Detection of the Idle Channel Condition 


Detection of the Idle Channel condition may be either ignored; 


or, if a flag sequence is not received within a period of time 
(Ti), considered as an event causing a change to the 
disconnected phase (see § 2.2.12.2). 
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SET REPLY TIMER 


FUNCTION: Reset Reply Timer Tp 


If Unacknowleged I-Frames Remain, Start Tp - 

Upon correct receipt of a frame acknowledging some previously 
transmitted |-frames(s) (containing an Nr that is higher than 

the last Nr received), DTEs reset (stop) Reply Timer Tp and 

if additional unacknowledged !-frames(s) are still 

outstanding they restart Reply Timer Tp. 


SET SND SEQ 


FUNCTION: Set Send Sequence. 


Set the send sequence variable (Vs) equal to the 
value of Nr contained in the received frame 
(see §-2.4.5.5). 


OUTPUT _UPM 


FUNCTION: Output_UPM 


The Output Undefined Protocol Machine (UPM) is invoked 
from SLP_FSM, SLP_FSM_OPENED and SLP_FSM_CHECKPOINT protocol 
machines to initiate and manage transmissions on the output 
link channel. Functions of the output_UPM include, but are 
not necessarily limited to: : 
. maintenance of a link outbound queue; 
. maintenance of a retransmission queue; 
. utilization of the outbound link channel; 
. initialization of the transmission count variable; 
Parameters passed to the output_UPM include: 
1. (Acknowledgement) - denoting receipt of acknowledgment for 
one or more previously transmitted |-frames and advancement 


of the lower transmit window edge; 


2. (Data) - denoting receipt of data to be transmitted from a 
higher layer user; and 


3. (Null) - denoting occurrence of the output link channel 
idle event. 


REPORT_STATUS 


FUNCTION: Report Status 


A higher layer may be informed of the event/condition/state 
using DTE specific internal signalling mechanisms 
(see §§ 2.4.3.1, and 2.4.4.1, and 2.4.4.3). 
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CONVENIENT RESP OPPORTUNITY 


FUNCTION: Convenient Response Opportunity 


When at a convenient respond opportunity, for example, the 

DTE received several | frames and should send an Nr to the DCE. 
it may send the Nr within an | frame or supervisory frame that 

it has a need to send to the DCE. 

The transmission must occur prior to the expiration of T1. 


jee aepremaaarystereennaartesareutnaey thine errant See eeata tine nese ae 


RESPONSE TO _CMD_ REQUIRED 


FUNCTION: Response To Command Required 
When a response to a command received with ‘P=1’ 


is required, a response with F=1 must be sent at the first 
opportunity. 


PREPARED TO CONT OPERATION 


FUNCTION: Prepared To Continue Operation 


When prepared to continue operation with, or following, 
(rejinitialization of the SLP DTE/DCE interface. 


FUNCTION: Enabled And Prepared 
When the Single Link Procedure (SLP) is enabled and prepared to 


(re)initialize the SLP DTE/DCE interface and support the 
transfer of information. 
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A ppendix M. Description of the Enhanced Logical Link | a 
Control - (ELLC) Procedures 


The formats and protocols described in this appendix are adaptations of 
Asynchronous Balanced Mode (ABM) formats defined for HDLC and the 
X.25 Link Access Procedure - Balanced (LAPB) elements of procedure 
expanded to include an adaptation of the checksum data integrity mech- 
anism defined for IS-8073 (Open Systems Interconnection Transport Pro- 
tocol Specification in ISO/TC-97/SC-6-N3240) dated September 1984. 


M.1 Functional Overview 


M.1.1 Architecture 
Architecture to meet SNA quality of service requirements in packet- 
switched data network environments: 


e defines a Connection Type Indicator (CTI) within the 
Call User Data field of X.25 CALL REQUEST packets to distinguish 
between initial connection requests and connection recovery 
requests for ELLC; 


e« defines a Connection Identifier (CID) field in Call Set-up packets to 
carry Link _Connection_Identitication information between adjacent 
link stations; 


e defines LPDU headers for use the User_Data field of X.25 DATA 
packets and DATA packet sequences to perform sequenced trans- 
fers of BTUs between link stations in adjacent SNA nodes that 
include: 


— atwo-byte address field; 
— an extended (two-byte) control field; 
— atwo-byte checksum field; and, 


e defines recoverable call clearing, virtual circuit resetting and inter- 
face restarting cause codes together with link connection recovery 
procedures. 


M.1.2 Link Connection Service 
With a one-for-one correspondence between DLC.X25 link connections and 
X.25 virtual circuits, link connection services required for logical link 
control, to meet quality of service enhancement objectives in PSDN envi- 
ronments, are provided by adaptation of existing X.25 Packet Layer call 
set-up and clearing procedures. 
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M.1.3 Link Connection Identification | 
Since a one-for-one correspondence exists between X.25 logical channels 
and LLC link stations, X.25 logical channel identifiers (LCls) can be used 
by LLC to route DATA packets to the appropriate link station. DLC.X25 
link connection identification requirements are satisfied by correlating X.25 
Calling DTE Addresses, concatenated with a Connection Identifier carried 
in CALL REQUEST packets when parallel virtual calls are employed 
between DTEs, with X.25 logical channel identifiers. 


M.1.3.1 Permanent Virtual Circuit Services 
The relationship between DLC.X25 link connections employing permanent 
virtual circuits and X.25 logical channel identifiers are fixed by bilateral 
agreement between communicating link stations; therefore, X.25 logical 
channel identifiers can suffice for both LLC routing and error recovery 
functions, in this environment. 


M.1.3.2 Switched_Virtual_Circuit (Virtual Call) Services 
since X.25 lonical channel identifiers for switched virtual circuits are 
dynamically assigned at call set-up time, they suffice only for the LLC 
routing function; and, are correlated to X.25 Calling DTE Addresses, con- 
catenated with the Connection Identifier as required, for use in error situ- 
ations requiring re-connection procedures. 


M.1.4 Error Detection and Recovery 
LLC error detection and recovery requirements are satisfied by ELLC 
which, when selected, provides mechanisms to detect, and procedures to 
attempt recovery from, the loss, duplication and/or corruption of LPDUs by 
underlying network services. ELLC incorporates sequence numbering and 
validity checking mechanisms, as well as circuit assurance procedures. 


M.1.4.1 Sequence Numbering 
ELLC formats and protocols provide for the sequenced (modulo 128) 
transfer of information LPDUs, together with LPDU acknowledgment and 
retransmission recovery procedures to guard against the loss or dupli- 
cation of LPDUs, or both. 


M.1.4.2 Validity Checking 
ELLC also eniploys a checksum mechanism to detect LPDUs that have 
been corrupted by underlying network services and to insure the integrity 
of BTUs delivered to higher layer using protocols. 


M.1.4.3 Circuit Assurance 
ELLC circuit assurance capability defines recoverable error conditions 
reported by PSDNs through CLEAR_, RESET_ and RESTART REQUEST 
packets, as well as procedures for ascertaining and performing actual 
circuit recoverability. 
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M.2 Scope and Field of Application 


The Logical Link Control (LLC) procedure is described as the element 
used to enhance the quality of service exhibited to higher layer SNA users 
by the underlying network services in supporting the transfer of informa- 
tion between adjacent SNA nodes in PSDN environments. 


The procedure uses the principles and terminology of the High Layer Data 
Link Control (HDLC) procedures specified by the International Organiza- 
tion for Standardization (ISO). 


The transmission facility is duplex. 


Compatibility of operation with the ISO balanced class of procedure (Class 
BA, options 1, 2, 8 and 12) is achieved using the provisions found in this 
specification. 


M.3 Link Protocol Data Unit Structure 


All transfers across ELLC link connections are in LLC Protocol Data Units 
(LPDUs) conforming to one of the formats shown in Figure M-1 which are 
contained in the User Data field of X.25 DATA packets or DATA packet 
sequences. 


3S 6 


A C | X Y 
16-bits 16—bits 2 Octets* 


Supervisory and Unnumbered Format 


3 4 


5 6 


C X 4 
16-bits 2 Octets* N-Octets* 


Information Format 


PDUCS = Protocol Data Unit Checking Sequence — (Checksum) 
* an Octet is an 8-bit byte. 


Figure M-1. LPDU Formats: Supervisory and Unnumbered versus Information 
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M.3.1 Address (A) Field 
The LPDU address is a two-octet (16-bit) field which has the format shown 
in Figure M-2. The A field is positioned as shown in Figure M-1 on 


page M-3 and coded as described in “Procedure for Addressing” on 
page M-15. 


| Octet 1 | Octet 2 | 


Address Bits 


where: 
ADDRESS - is reserved and set to zeroes; and 


x - is the LPDU command/response (C/R) indicator which is set to: 
‘0’ in command LPDUs; and, 
‘4’ in response LPDUs. 


Figure M-2. LPDU Address Field Format 


M.3.2 Control (C) Field 


The C field is two octets positioned as shown in Figure M-1 on page M-3 
whose content is described in “LPDU Formats and State Variables” on 
page M-5. 


M.3.3 Information (I) Field 


The I-field of LPDUs transmitted and received by link stations contain an 
SNA Path Information Unit (PIU) consisting of an integral number of octets 
(8-bit bytes). 


Note: 


LPDUs containing other than an integral number of octets may be 
ignored at the physical or link layer. 


See “LLC Protocol Data Unit Reject (L_PDUR) Response” on page M-10 
and “Maximum Number of Bytes in an IPDU - (LN1)” on page M-24 with 
regard to the maximum information field length. 


M.3.4 Protocol_Data_Unit_Checking Sequence (PDUCS) Field 
The PDUCS field is two octets positioned as shown in Figure M-1 on 
page M-3 whose content is described in | 
“Protocol Data_Unit_Checking Sequence (PDUCS)” on page M-13. 
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M.3.5 Order of Transmission 
Address, control, sequence number, Protocol Data Unit Checking 
Sequence (PDUCS) and information octets are transmitted in ascending 
octet number order as indicated in Figure M-1 on page M-3 low order bit 
first. 


M.3.6 Invalid LPDUs 


LPDUs having fewer than forty-eight bits (six octets) are invalid. 


M.3.7 Link Channel States 


A link channel is defined as the means of transmission for one direction. 


M.3.7.1 Active State 
A link channel is in an active condition when the link station is actively 
transmitting an LPDU. 


M.3.7.2 Idle State 
A link channel is defined to be in an idle condition when the link station 
fails to receive an LPDU for a system specified period of time. 
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M.4 Elements of Procedure 


The elements of procedure are defined in terms of actions that occur on 
receipt of commands or responses or the occurrence of events, at FLLC 
link stations. 


The elements of procedure specified here contain a selection of com- 
mands and responses relevant to the ELLC link connection and system 
configuration described in “Scope and Field of Application” on page M-3. 


A procedure derived from these elements of procedure ts described in 
“Description of the Procedure” on page M-15. Together “Link Protocol 
Data Unit Structure” on page M-3 and “Elements of Procedure” form the 
general requirements for proper management of link connections between 
ELLC link stations in adjacent nodes. 


M.4.1 LPDU Formats and State Variables 
The various LPDU formats and link station state variables used for ELLC 
are described under “Control (C) Field Formats” and “Control Field 
Parameters” on page M-6. 


M.4.1.1 Control (C) Field Formats 
The C field contains a command or a response, and sequence numbers, 
where applicable. Three LPDU C-field formats as shown in Figure M-3 on 
page M-6 are defined for use, which include: 


« IPDUs - to perform sequenced information transfers; 
® SPDUs - to perform numbered supervisory functions; and 
° UPDUs - to perform unnumbered control functions. 
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Second Octet First Octet 
Control field bits 8765432 


Information (IPDU) 
Supervisory (SPDU) 


Unnumbered (UPDU) 


transmitter send sequence number (bit 2 = low order bit). 
= transmitter receive sequence number (bit 2 = low order bit). 
= Supervisory function bit. 
= modifier function bit. 
poll (P) bit in command frames or final (F). bit in response 
frames (1 = Poll/Final). 


Figure M-3. LPDU Control Field Formats 


Information _Protocol_Data_Unit - IPDU: used to perform sequenced infor- 
mation transfers. Except as otherwise specified (i.e., LPDUR, LTEST, 
LXID) it is the only LPDU that may contain an information field. The func- 
tions of LNs, LNr and P/F are independent; t.e., each IPDU has an LNs, 
and an LNr which may or may not acknowledge additional IPDUs received 
by the ELLC link station transmitting the LNr, and a P/F bit. 


Supervisory_Protocol_Data_Unit - SPDU: used to perform link supervisory 
control functions such as acknowledging IPDUs, requesting retransmission 
of IPDUs, and requesting temporary suspension of IPDU transmission. 


Unnumbered_Protocol_Data_Unit - UPDU: used to provide additional link 
control functions. This format contains no sequence numbers. 


M.4.1.2 Control Field Parameters 
Parameters associated with the control field formats include a modulus 
(m), LPDU variables and sequence numbers. 


Modulus - ‘m’: !PDUs are sequentially numbered and may have the value 
‘LNs =0’ through ‘LNs=m minus one’ (where ‘m’ is the modulus of the 
sequence numbers). ‘m’ is equal to ‘128’ and the sequence numbers 
cycle through the entire range ‘0’ to ‘127’, inclusive. 


State Variables and Sequence Numbers 
e Link Send State Variable (LVs) 


LVs denotes the sequence number of the next in-sequence IPDU 
to be transferred across the link connection. LVs can take on the 
value 0’ through ‘m minus one’. The value of LVs is incremented 
by one with each successive IPDU transferred but at originating 
link stations cannot exceed LNr of the last received IPDU or SPDU 
by more than the maximum permissible number of outstanding 
IPDUs (Lk). The value of ‘Lk’ is defined in “Maximum Number of 
Outstanding IPDUs - (Lk)” on page M-24. 


¢ Link Send sequence Number (LNs) 
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Only IPDUs contain LNs, the send sequence number of transferred 
PDUs. Prior to transferring an in-sequence IPDU, the value of LNs 
is set equal to the value of LVs at the originating link station. 


e Link Receive State Variable (LVr) 


LVr denotes the sequence number of the next in-sequence IPDU to 
be received at destination link stations. LVr can take on the 
values 0’ through ‘m minus one’. The value of LVr is incremented 
by one upon receipt of each error free, in-sequence (with an LNs 
that is equal to the current value of LVr at the receiving link 
Station) IPDU. 


e Link Receive Sequence Number (LNr) 


All IPDUs and SPDUs contain LNr, the expected sequence number 
of the next received IPDU. Prior to transmitting an IPDU or SPDU, 
LNr is set equal to the current value of LVr at the originating link 
Station. LNr indicates that the link station transferring the LNr has 
correctly received all IPDUs numbered up to and including ‘LNr 
minus 1°. 


M.4.1.3 Functions of the Poll/Final Bit 
The poll/final (P/F) bit serves a function in both command LPDUs and 
response LPDUs. In command LPDUs the ‘P/F’ bit is referred to as the 
Poll (P) bit. In response LPDUs it is referred to as the Final (F) bit. 


Procedures for use of the ‘P/F’ bit are described in “Procedure for Use of 
the P/F Bit” on page M-15. 


M.4.2 Link Commands and Responses 
Command and response LPDUs transmitted and received by link stations 
in adjacent nodes are depicted in Figure M-4 on page M-8 and are 
described in “LLC Information (LI) Command” through “LLC Test (LTEST) 
Command and Response” on page M-11. 


M.4.2.1 LLC Information (LI) Command 
LI commands are used to transfer sequentially numbered PDUs that 
contain information fields, across link connections between link stations in 
adjacent ncdes. 


M.4.2.2 LLC Receive Ready (LRR) Command and Response 
LRR command/response SPDUs are used by link stations to: 
e jndicate that they are prepared to receive IPDUs 
e acknowledge previously received IPDUs numbered up to and 


including ‘LNr minus 1’. 


LRR command/response SPDUs may be used to clear busy conditions ini- 
tiated by the prior transmission of LRNR command or response SPDUs. 
LRR command SPDUs with ‘P = 1’ may be used by link stations to solicit 
the status of the communicating link station in the adjacent node. 
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N 
0 LRNR LRNR 
3 
e LREJ urea | 


LDISC = 


LDM 
LPDUR 


LI = 


LREJ 
LRNR 
LRR 


LSABME = 


LUA 


LXID = 


LIES 


Note: 


Second Octet 


Disconnect 

Disconnected Mode 
Protocol Data Unit Reject 
Information 

Reject 

Receive Not Ready 

Receive Ready 


First Octet 
Bit Positions 


Set Asynchronous Balanced Mode — Extended 


Unnumbered Acknowledgment 
Exchange Identification 
Test 


Figure M-4. LPDU Commands and Responses 


M.4.2.3 LLC Reject (LREJ) Command and Response 


LREJ command/response SPDUs are used by link stations to request 


retransmission of IPDUs starting with the IPDU numbered LNr. 


Link stations transmit all Supervisory and Unnumbered command 
LPDUs with 'P=1'. 


IPDUs | 


numbered ‘LNr minus 1’ and below are acknowledged. Additional IPDUs 
pending initial transmission may be transmitted following the retrans- 


mitted IPDU(s). 


Only one LREJ exception condition for a given direction of information 
transfer may be established at any time. LREJ exception conditions are 


M-8 Architecture Reference 


cleared (reset) upon receipt of an IPDU with an LNs equal to the LNr con- 
tained in the LREJ SPDU. 


M.4.2.4 LLC _Receive_Not_Ready (LRNR) Command and Response 
LRNR command/response SPDUs are used by link stations to indicate 
busy conditions; i.e., temporary inability to accept additional IPDUs. 
[PDUs numbered up to and including ‘LNr-1’ are acknowledged. IPDU LNr 
and subsequent IPDUs received, if any, are not acknowledged; the accept- 
ance status of these IPDUs is indicated in subSequent exchanges. 


Indication that a busy condition at a link station has cleared is communi- 
cated to the communicating link station in the adjacent node by the trans- 
mission of an LUA, LRR, LREJ or LSABME. 


LRNR command SPDUs with the ‘P = 1’ may be used by link stations to 
solicit the status of the communicating link station in adjacent nodes. 


M.4.2.5 LLC Set_Asynchronous_ Balanced_Mode_Extended (LSABME) Command 
LSABME commands are used to initialize/re-initialize both directions of 
transmission across the link connection between link stations in adjacent 
nodes. The DLC.X25.CM initiates transmission of the LSABME command 
upon receipt of a “CONTACT ALS” from SNA.PU. No information field is 
permitted with this command. Link stations in adjacent nodes confirm 
acceptance of LSABME commands by transferring an LUA response 
across the link connection at the earliest opportunity. Upon acceptance of 
an LSABME command, the communicating tink station in the adjacent 
node sets both its send and receive state variables (LVs and LVr) equal to 
‘0’ and assumes the link asynchronous balanced mode - extended. When 
the LUA response is correctly received, the initiating link station also 
assumes the link asynchronous balanced mode - extended and sets its 
send and receive state variables (LVs and LVr) equal to (0. LSABME 
commands are always transferred with ‘P = 1. 


Previously transferred IPDUs that are unacknowledged when the LSABME 
command is initiated and executed remain unacknowledged (see “Waiting 
for Acknowledgement” on page M-20). Any transmit buffers that are 
unacknowledged or pending initial transmission are purged from the link 
station queue and returned to the upper layer user function. 


M.4.2.6 LLC_Disconnect (LDISC) Command 
LDISC commands are used by link stations to terminate the operational 
mode previously set. LDISC informs the communicating link station in the 
adjacent node that the link station is temporarily suspending operation. 


No information field is permitted with LDISC commands. Prior to exe- 
cuting LDISC commands, receiving link stations confirm acceptance by 
transmitting an LUA response. Transmitting link stations enter the link 
disconnected phase upon receipt of the acknowledging LUA response. 
LDISC command LPDUs are always transmitted with ‘P = 1. 


Previously transmitted IPDUs that are unacknowledged when the LDISC 


command is executed remain unacknowledged (see “Waiting for 
Acknowledgement” on page M-20). 
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M.4.2.7 LLC Unnumbered_Acknowledgment (LUA) Response 
LUA responses are used by originating link stations to acknowledge 
receipt and indicate acceptance of LSABME and LDISC commands. 
Receiving link stations transfer an LUA response before executing the 
received UPDU command. The LUA response is transferred with ‘F = 1’ 
when ‘P = 1’ in the UPDU command being acknowledged. No information 
field is permitted with LUA responses. 


M.4.2.8 LLC _Disconnected_Mode (LDM) Response 
LDM responses are used to report a status where the originating link 
Station is logically disconnected, and is in the LLC disconnected phase. 
The LDM response may be sent in response to a received LSABME 
command, to inform the adjacent node link station that the originating link 
station is still in the LLC disconnected phase and cannot execute the 
LSABME command. No information field is permitted with the LDM 
response. 


Link stations in the link disconnected phase monitor received commands 
and: 


e react to LSABME and LDISC commands as described in “Link Dis- 
connected Phase” on page M-17; and, 


e« transfer an LDM response with ‘F = 1’ to any other UPDU 
command received with ‘P = 1’. 


M.4.2.9 LLC Protocol Data_Unit_Reject (LPDUR) Response 
LPDUR responses are used by link stations to report error conditions that 
are not recoverable by retransmission of the identical LPDU to the adja- 
cent link station; i.e., one of the following conditions, resulting from the 
otherwise error free receipt of an LPDU with: 


e a LPDU command or response that is invalid or not implemented; 
e an information field that exceeds the maximum permissible length; 
e an invalid LNr; or, 


e an information field which is not permitted or an SPDU or UPDU of 
incorrect length. 


An invalid LNr is one that points to an IPDU that has been previously 
transmitted and acknowledged or to an IPDU that has not been trans- 
mitted and is not the next sequential IPDU pending transmission. 


An information field which immediately follows the control field, and con- 


sists of 5 octets, is returned with the LPDUR response. This format is 
shown in Figure M-5 on page M-11. 
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Rejected LPDU 


Control Field 


- Rejected LPDU control field is the control field of the received LPDU that 
caused the PDU reject condition. 

- LVs is the current value of LVs at the link station reporting the rejec- 
tion condition {bit 23 = low order bit). 

-LVr is the current value of LVr at the link station reporting the rejec- 
tion condition (bit 31 = low order bit). 

- ‘W=1' indicates that the control field received and returned in bits 1 
through 16 was considered invalid or not implemented. 

- X=1' indicates that the control field received and returned in bits 1 
through 16 was considered invalid because the LPDU contained an informa- 
tion field which is not permitted or is an SPDU or UPDU with incorrect 
length. ‘W=1’ is required in conjunction with this bit. 

- ‘Y=1' indicates that the information field received exceeded the maximum 
established capacity of the link station reporting the condition. 

- Z=1 indicates that the control field received and returned in bits 1 
through 16 contained an invalid LNr. 

- C/R - Bit 32 is set to: 

‘1’ if the rejected LPDU was a response; or, 
‘0’ if the rejected LPDU was a command. 


Figure M-5. LPDUR Information Field Format 


M.4.2.10 LLC Exchange_ Identification (LXID) Command and Response 
LXID commands are used by ELLC link stations to initiate exchanges of 
identification information with link stations at adjacent SNA nodes. 


M.4.2.11 LLC Test (LTEST) Command and Response 
LTEST commands are used by ELLC link stations to initiate tests of link 
connections and solicit an LTEST response from ELLC link stations in 
adjacent nodes. 


M.4.3 Exception Condition Reporting and Recovery 
Procedures to effect recovery following the detection/occurrence of excep- 
tion conditions on the connection between link stations in adjacent SNA 
nodes are described in “Busy Condition” on page M-12 through “LPDU 
Rejection Condition” on page M-14. Exception conditions described 
include situations that may occur as the result of underlying network mal- 
functions or abnormal operationa! situations. 
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M.4.3.1 Busy Condition 
A busy condition results when an ELLC link station is temporarily unable 
to continue receiving IPDUs due to internal constraints (e.g., receive buf- 
fering limitations). Notification of the busy condition is conveyed to the 
link station in the adjacent node by transferring an LRNR across the link 
connection. IPDUs pending transmission may be transmitted by link | 
stations experiencing a busy condition, either prior to, or following, trans- 
mission of the LRNR. Recovery from a link station busy condition is indi- 
cated to link stations in adjacent nodes as described in 
“LLC Receive _Not_Ready (LRNR) Command and Response” on 
page M-9. 


M.4.3.2 LNs Sequence Error 
A sequence exception condition results when an error-free (no PDUCS 
error) IPDU with an LNs that is not equal to the current value of LVr at the 
receiving link station is received. Receiving link stations do not acknowl- 
edge (increment their LVr) [PDUs that result in sequence exception condi- 
tions. 


The information field of all IPDUs received with an LNs that is not equal to 
the current value of LVr at the receiving link station is discarded. 


ELLC link stations that receive one or more IPDUs having sequence errors 
but otherwise error-free accept the control information contained in the 
LNr field and the ‘P’ bit to perform link control functions (e.g., to receive 
acknowledgment of previously transmitted IPDUs and to cause the link 
station to respond (‘P = 17)). Therefore, retransmitted IPDUs may contain 
an LNr field and ‘P’ bit that are updated, and therefore different from, 
those contained in the IPDU(s) originally transmitted. 


M.4.3.3 LLC REJECT Recovery 
LREJ commands and responses are transferred by link stations to initiate 
exception recovery (retransmission) following detection of sequence 
errors. 


Only one “sent LREJ” exception condition for a link station is established 
at atime. A “sent LREJ” exception condition is cleared when the 
requested IPDU is received; or, when a link set-up or disconnection proce- 
dure as described in “Link Resetting Procedures” on page M-21 is per- 
formed. 


Link stations. receiving LREJ initiate sequential (re-)transmission of IPDUs 
Starting with the one indicated by the LNr contained in the received LREJ 
SPDU, if possible (see “Maximum Number of LPDU Transmissions - (LN2) 
on page M-24). 


Ph) 


M.4.3.4 Time-out Recovery 
If, due to a transmission error, a link station does not receive (or receives 
and discards) a single IPDU or the last IPDU in a sequence of IPDUs, it 
cannot detect an out-of-sequence exception condition and will, therefore, 
fail to transmit an LREJ. Link stations shall, following completion of a 
system specified time-out period (see “LLC Time-Out_ Function - (LFt)” on 
page M-23) take appropriate recovery action to determine at which IPDU 
retransmission must begin. | 
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Link stations use the lost reply protection mechanism, described in “Lost 
Reply Protection” on page M-15, after a system specified time-out period 
(see “LLC Time-Out Function - (LFt)” on page M-23) to determine at 
which IPDU to begin retransmission. 


M.4.3.5 Protocol_Data_Unit_Checking Sequence (PDUCS) 
The purpose of the PDUCS is to detect LPDUs that have been corrupted 
by the underlying network service. 


When an LPDU is to be transmitted the sending link station must generate 
a PDUCS for the LPDU and store it in the PDUCS parameter in the LPDU 
header. 


e PDUCS (Checksum) Generation Procedure 


— Set up the complete LPDU, including the header and user data 
(if any). The header must include the PDUCS parameter. The 
value field of the PDUCS parameter must be set to zero at this 
point. 


— Initialize two variables (called C° and C') to zero. 


~ For each octet of the LPDU, including the header and the user 
data (if any), add the octet value to C°, and then add the value 
of C° to C!. Octets are processed sequentially, starting with 
the first octet and proceeding through the LPDU. Addition is 
performed modulo 256. 


— Calculate the value field of the PDUCS parameter as follows: 


— Let the length of the LPDU, i.e., the number of times the 
above operation was repeated be ‘L’; 


— Let the first octet of the PDUCS value, i.e., the nth octet of 

the LPDU, (where ‘n=9'for ELLC architecture), be called 

x: 

— Let the second octet of the PDUCS value, i. e., the (n+1)th 
octet (where ‘n=5' for ELLC architecture), be called ‘Y’. 


Then: 
X 


HH 


(((L - i) * C®) - C1) modulo 256; and, 


Y = (((L - n +1) * (- C®)) + C1) modulo 256 


— Place the computed values of ‘X’ and ‘Y’ in the appropriate 
octets of the LPDU. 


Note: 


An implementation may use one’s complement arithmetic 
as an alternative to modulo 256 arithmetic. However, if 
either of the PDUCS octets ‘X’ and ‘Y’ has the value minus 
zero (I.e., X FF’) then it must be converted to plus zero (i.e., 
x00") before being stored. 


e PDUCS (Checksum) Validation Procedure 


When an LPDU is received it is verified to ensure that it has been 
received correctly. This is done by computing the PDUCS, using 
the same algorithm by which it was generated. The nature of the 
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PDUCS algorithm is such that it is not necessary to compare 
explicitly the stored PDUCS octets. The procedure described 
below may be used to verify that an LPDU has been correctly 
received. 


— Initialize two variables (called C° and C’) to zero. 


— For each octet in the received LPDU, add the value of the 
octet to C° and then add the value of C° to C?, starting 
with the first octet and proceeding sequentially through the 
LPDU. All addition is performed modulo 256. 


— When all octets have been sequentially processed, the 
values of C° and C! should be zero. If either or both of 
them is non-zero, the LPDU has been received incorrectly 
and the verification has failed. Otherwise, the LPDU has 
been received correctly and the LPDU is processed 
normally. 


Note: 


An implementation may use one’s complement arith- 
metic as an alternative to modulo 256 arithmetic. In 
this case, if either C° or C! has the value minus zero 
(i.e., X'FF’) it regarded as though it was plus Zero (.e., 
x‘00’). | 
lf a PDUCS verification failure occurs, the received LPDU is discarded 
and no actions is taken by any link station at the receiving DTE as a 
result of that LPDU. 


M.4.3.6 LPDU Rejection Condition 
An LPDU rejection condition may be established upon receipt of an error- 
free LPDU that contains an invalid command/response in the C field, an 
invalid LPDU format, an invalid LNr or an information field that exceeds 
the maximum information field length that can be accommodated. 


Receiving ELLC link stations report LPDU rejection conditions to the com- 
municating link station in the adjacent node by transferring an LPDUR 
response across the link connection. ELLC link stations that receive an 
LPDUR response are responsible for resolving the rejection condition by 
initiating either a link resetting or link disconnection procedure; or, by 
causing a clearing or resetting of the underlying virtual circuit. After 
transmitting an LPDUR response, ELLC link stations maintain the LPDU 
rejection condition until the link is reset by the communicating link station 
in the adjacent node. IPDUs received by ELLC link stations in the LPDU 
rejection condition are discarded, except for the ‘P’ bit indication (LNr is 
ignored). The LPDUR response may be repeated at each opportunity until 
recovery is effected by the communicating link station in the adjacent 
node, or until internal recovery is initiated locally. 


M.4.3.7 Recoverable Packet Layer Error Conditions 
- Network initiated virtual circuit terminations (clears) and re- 
~ synchronizations (resets), as well as interface re-initializations (restarts) 
are considered to be potentially recoverable at the logical data link 
control layer. These are indicated by receipt of indication packets con- 
taining ‘Cause Codes’ other than the DTE-Generated codes, x‘00’ and 
x80’. 


M-14 Architecture Reference 


+ M.4.3.8 Effects of LAPB Link Resetting 


++ +4 444 


M.5.1 Procedure 


Resetting of the data link layer re-initializes LAPB sequence numbering 
and constitutes an exposure to the integrity of data, for either direction of 
transmission. Such exposures may be resolved via logical link stations 
using ELLC sequence numbering and verification procedures; and, actual 
errors are logged and either: 


e recovered by retransmission; or, 
¢ reported to the higher layers of SNA. 
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M.5 Description of the Procedure 


The charts in “Link Station States and Actions” on page M-36 detail the 
actions, LPDU transfers and state transitions that result from stimuli that 
can occur at ELLC link stations in the various states of link connections. 


for Addressing 
LPDUs are transferred with the address field set to indicate their 
command/response content. 


M.5.2 Procedure for Use of the P/F Bit 


Upon receipt of any command LPDU with ‘P = 1’, ELLC link stations 
transfer an appropriate response LPDU with ‘F = 1’ across the link con- 
nection at the first respond opportunity (e.g., immediately following the 
LPDU currently being transmitied, if any). Appropriate responses include: 


e an LUA or LDM response to received LSABME and LDISC com- 
mands; 


« an LPDUR, LREJ, LRNR or LRR response to received IPDU com- 
mands; ana, 
® an LXID or LTEST response to received LXID or LTEST commands, 


respectively; 


e an LPDUR, LRNR or LRR response to received SPDU commands. 


The ‘P’ bit is also used in conjunction with timer recovery conditions as 
described in “Waiting for Acknowledgement” on page M-20 and may be 
used as a request for acknowledgment on IPDUs and invitation to 
transmit, by the upper layer user(s), in application environments that 
exhibit half-duplex characteristics. 


perenne enna eH Pen emi ns 


M.6 Lost Reply Protection 


ELLC link stations provide a time-out function to protect against dead-lock 
conditions caused by loss of responses from communicating link stations 
in the adjacent node due to transmission errors. An LLC Reply Timer, 
[T1, may be started upon transmission of IPDUs or SPDU commands, or 
both, during the information transfer phase. LLC Reply Timer, LT1, is also 
used as described in “Link Set-up” on page M-16 and “Link 
Disconnection” on page M-16. 


If LLC Reply Timer, LT1, expires prior to receipt of an appropriate 
response from the communicating link station in the adjacent node, ELLC 
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link stations initiate action to recover the link connection. ELLC link 
stations transfer an appropriate command SPDU and restart LLC Reply 
Timer, LT1. If LLC Reply Timer, LT1, expires prior to receipt of an appro- 
priate response with ‘F = 1° LN2 times, appropriate recovery action is ini- 
tiated. 


M.6.1 Procedures for Link Set-Up and Disconnection 


M.6.1.1 Link Set-up 


M.6.1.2 


ELLC link stations wishing to set-up the link connection transfer an 
LSABME command with ‘P = 1’ and start LLC Reply Timer, LT1 (see 
“LLC Time-Out_Function - (LFt)” on page M-23). Upon receipt of an LUA 
response with ‘F = 1’ from the link station in the adjacent node, the initi- 
ating ELLC link station sets both LVs and LVr equal to ‘0’ and stops LLC 
Reply Timer, LT1. 


Upon receipt of an LSABME command, receiving ELLC link stations pre- 
pared to receive IPDUs return an LUA response and set both LVs and LVr 
equal to ‘0’. ELLC link stations that, for some reason, are unable or do 
not desire to enter the information transfer phase, return an LDM 
response to received LSABME commands. 


Upon receipt of an LDM response with ‘F = 1’ indicating that the adjacent 
link station cannot accept activation of the link connection, the condition is 
reported to the upper layer user and no further action is taken by logical 
link control. 


Upon expiration of LLC Reply Timer, LT1, prior to receipt of an appropriate 
response with ‘F = 1’, ELLC link stations perform the retransmission pro- 
cedure described in “LLC Time-Out_Function - (LFt)” on page M-23 

before declaring the link connection to be inoperative and reporting the 
condition to a higher layer of SNA. 


Information Transfer Phase 


ELLC link stations, having transferred an LUA response to a received 
LSABME command or having received an LUA response to a transmitted 
LSABME command, accept and transmit |PDUs and SPDUs in accordance 
with the procedures described in “Procedures for Information Transfer” on 
page M-17. 


Upon receipt of an LSABME command, an LUA response or an LDM 
response with ‘F = 0’, while in the information transfer phase, ELLC link 
stations conform to the resetting procedure described in “Link Resetting 
Procedures’ on page M-21. 


M.6.2 Link Disconnection 


During the information transfer phase ELLC link stations, wishing to termi- 
nate the link connection, transfer an LDISC command with ‘P = 1’ across 
the link connection and start LLC Reply Timer, LT1, {see 

“LLC Time-Out_Function - (LFt)” on page M-23). 


Upon receipt of a LDISC command, receiving ELLC link stations return an 
LUA or LDM response and enter the link disconnected phase. 


M-16 Architecture Reference 


Upon receipt of an LUA or LDM response with ‘F = 1’ from the communi- 
cating link station in the adjacent node, initiating ELLC link stations stop 
LLC Reply Timer, LT1. 


Upon expiration of LLC Reply Timer, LT1, prior to receipt of an appropriate 
response with ‘F = 1’, ELLC link stations perform the retransmission pro- 
cedure described in “LLC_Time-Out_Function - (LFt})” on page M-23 

before declaring the link connection to be inoperative and reporting a 
failure to the higher layers of SNA. 


M.6.2.1 Link Disconnected Phase 
ELLC link stations, having received an LDISC command and returned an 
LUA response, or having received an LUA response to a transmitted 
LDISC command, enter the link disconnected phase. 


ELLC link stations, in the link disconnected phase, may initiate link set-up. 
While in the link disconnected phase, ELLC link stations react to the 
receipt of LSABME commands as described in “Link Set-up” on 

page M-16 and transfer an LDM response to received LDISC commands. 


Upon receipt of any command (other than LSABME) with ‘P 


— 1’, 
receiving ELLC link stations transfer an LDM response with ‘F = 


ale 


Other LPDUs are ignored by receiving ELLC link stations while in the link 
disconnected phase. 


M.6.2.2 Collision of UPDU Commands 
UPDU command collision situations are resolved in the following manner. 


Like Commands: When the sent and received UPDU commands are the 
same, both ELLC link stations transfer an appropriate UPDU response at 
the earliest possible opportunity. ELLC link stations place the associated 
link connection in the indicated state upon receipt of the appropriate 
UPDU response. 


Unlike Commands: When the sent and received UPDU commands, other 
than LXID and LTEST, are different ELLC link stations place the associated 
link connection in the LINK CLOSED state and transfer an LDM response 
at the earliest possible opportunity. When the sent and received UPDU 
commands are LXID or LTEST, ELLC link stations transfer the appropriate 
LTEST and LXID response, respectively, when available. 


M.6.3 Procedures for Information Transfer 
These procedures apply to the transmission of IPDUs in each direction of 
transmission during the link information transfer phase. 


In the following text, “number one higher” is in reference to a contin- 


uously repeated sequence series, i.e., 127’ is one higher than ‘126’ and ‘0’ 
is one higher than ‘127’ for modulo one hundred twenty eight series. 
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M.6.3.1 Sending IPDUs | | 
ELLC link stations having IPDUs to transfer (i.e., IPDUs not already trans- 
ferred, or having to be retransmitted as described in “Receiving Reject” 
on page M-19 or “Waiting for Acknowledgement” on page M-20, transfer 
them with an LNs equal to the current value of that link stations LVs, and 
an LNr equal to the current value of the link stations LVr. Upon com- 
pletion of transmission of each successive IPDU, ELLC link stations incre- 
ment their LVs by one (1) and start LLC Reply Timer, LT1, if it is not 
already running. 3 


When the value of LVs, at an ELLC link station, is equal to the last value of 
’LNr received from the communicating link station in the adjacent node 
plus ‘Lk’ (where ‘Lk’ is the maximum permissible number of outstanding 
IPDUs allowed (see “Maximum Number of Outstanding IPDUs - (Lk)” on 
page M-24), that ELLC link stations does not transfer any new |IPDUs, but 
may retransmit |PDUs as described in “Receiving Reject” on page M-19 
or “Waiting for Acknowledgement” on page M-20. 


Note: 


To ensure the integrity of information transfer, ELLC link stations 
do not transfer any IPDUs when the link stations LVs is equal to 
the last value of LNr received from the link station in the adjacent 
node plus ‘127’. 


ELLC link stations in the busy condition may continue to transfer 
IPDUs, provided the communicating link station in the adjacent 
node is not also in a busy condition. ELLC link stations in the link 
rejection condition, do not transfer IPDUs. 


M.6.3.2 Receiving IPDUs 
ELLC link stations not in the busy condition accept the I-field of in- 
sequence IPDUs (IPDUs with an LNs equal to the current value of the link 
stations LVr) received with the correct PDUCS, increment the value of the 
link stations LVr by one and acknowledge receipt of the IPDU(s) by trans- 
ferring: 


e the next sequential IPDU to be transferred, if it is available, or an 
LRR response SPDU with LNr equal to the current value of its LVr; 
or, 


e an LRR response SPDU response with LNr equal to the current 
value of its LVr, if no IPDU is available to transfer. 
ELLC link stations may ignore the information field contained in IPDUs 
received while they are in a busy condition. 


Note: 


ELLC link stations treat IPDUs with zero length information fields 
the same as any other IPDU at the link station. 
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M.6.3.3 Receipt of Incorrect LPDUs 


ELLC link stations ignore LPDUs received with an incorrect PDUCS and 
cause a Clearing or resetting of the underlying virtual call or permanent 
virtual circuit, respectively, upon receipt of LPDUs with invalid formats 
(see “Invalid LPDUs” on page M-5). 


ELLC link stations receiving [PDUs with the correct PDUCS, but with an 
incorrect LNs (i.e., one that is not equal to the current value of LVr at the 
receiving link station) discard the |-field and transfer an LREJ response 
with an LNr one higher than the LNs contained in the last correctly 
received IPDU. Then they discard the I-field, but use the LNr and ‘P’ bit 
indications of all IPDUs received with an LNs that is not equal to the 
current value of LVr at the receiving ELLC link station. Upon receipt of the 
expected IPDU (I.e., one with an LNs equal to the current value of LVr), 
receiving ELLC link stations acknowledge the IPDU as described in 
“Receiving IPDUs” on page M-18. 


M.6.3.4 Receiving Acknowledgement 


ELLC link stations, even in a busy condition, consider the LNr contained in 
correctly received IPDUs or SPDUs (LRR, LRNR and LREJ) as acknowledg- 
ment for all |IPDUs transferred with an LNs up to and including ‘LNr minus 
1’. ELLC link stations reset LLC Reply Timer, LT1, upon correct receipt of . 
an IPDU or SPDU that actually acknowledges some previously transferred 
IPDU({s) (i.e., an LPDU with an LNr higher than the value of the last LNr 
received); or, upon receipt of an SPDU with ‘F = 1’. 


If LLC Reply Timer, LT1, has been reset with IPDU(s) still unacknowl- 
edged, ELLC link stations restart LLC Reply Timer, LT1. If LLC Reply 
Timer, LT1, expires prior to receipt of an acknowledgment, ELLC link 
Stations follow-the retransmission procedure described in “Receiving 
Reject” and “Waiting for Acknowledgement” on page M-20 with respect to 
the unacknowledged IPDU({s). 


M.6.3.5 Receiving Reject : 
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Upon receipt of an LREJ SPDU, receiving ELLC link stations, supporting 
LPDU retransmission recovery (see “Maximum Number of LPDU Trans- 
missions - {LN2)” on page M-24), set LVs equal to the LNr contained in 
the received LREuJ, then transfer the corresponding |PDU when it ts avail- 
able or retransmit it; otherwise, they cause a clearing or resetting the the 
virtual circuit. 


ELLC link stations conform to the following with respect to the re- 
transmission of IPDUs: 


e An ELLC link station that is transmitting a SPDU or an UPDU when 
it receives a LREJ, will complete the transmission in progress 
before commencing transmission of the requested IPDU. 


e An ELLC link station that is transmitting an IPDU when an LREJ is 
received, may abort transmission of the IPDU and commence 
transmission of the requested IPDU immediately after aborting 
transmission of the IPDU currently being transmitted. 


e An ELLC link station that is not transmitting any LPDU when an 
LREJ is received, will commence transmission of the requested 
IPDU immediately. 
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Other unacknowledged IPDUs already transferred, following the one indi- 
cated in the LREJ, are retransmitted following retransmission of the 
requested IPDU. 


lf the LREJ was received as a command with ‘P = 1’, receiving ELLC link 
Stations transfer an LRR or LRNR response with ‘F = 1° prior to transmit- 
ting or retransmitting the corresponding IPDU. 


M.6.3.6 Receiving LRNR 
Upon receipt of an LRNR command or response SPDU, ELLC link stations 
may start Query Timer LTn if it is.not running. If Query Timer LTn then 
expires prior to the receipt of a LUA, LRR, LREJ or LSABME from the 
communicating link station in the adjacent node, ELLC link stations 
transmit an appropriate SPDU command with ‘P = 1° and may perform 
the retransmission procedure described under “LLC _Time-Out_Function - 
{LFt}” on page M-23 before declaring the link connection to be inoperative 
and reporting the condition to higher layer user(s). 


M.6.3.7 Link Station Busy Condition | 
ELLC link stations experiencing a busy condition transfer an LRNR 
command or response at a prudent opportunity. While in the busy condi- 
tion, ELLC link stations accept and process SPDUs and respond LRNR 
with ‘F = 1° to IPDUs and SPDU commands received with ‘P = 1’. To 
clear a busy condition, ELLC link stations transfer either LREJ commands 
or responses or LRR commands or responses with LNr set to the current 
value of LVr, depending on whether or not information fields of correctly 
received IPDUs were discarded. 


M.6.3.8 Waiting for Acknowledgement 
Originating ELLC link stations maintain an internal retransmission count 
(Y) which is set equal to ‘0’ upon receipt of an LUA or LRNR, or upon 
correct receipt of an IPDU or an SPDU with an LNr higher than the last 
LNr received from the communicating link station in the adjacent node 
(actually acknowledging some IPDU(s)). 


lf LLC Reply Timer, LT1, expires, ELLC link stations enter or ({re-}enter the 
timer recovery condition, increment ‘Y’ by one (1) and set an internal vari- 
able (X) to the current value of LVs. 


ELLC link stations restart LLC Reply Timer, LT1, set LVs equal to the 
value of the last LNr received from the communicating link station in the 
adjacent node and transfer an appropriate SPDU command with ‘P = 1’. 


Timer recovery conditions are cleared upon receipt of a valid SPDU 
response with ‘F = 1. 


Upon correct receipt of a SPDU response with ‘F = 1° and an LNr within 
the range from the current value of LVs to ‘X’ included, ELLC link stations 
reset the timer recovery condition and set LVs equal to the value of LNr in 
the received SPDU. | 


Upon correct receipt of an SPDU with ‘F = 0’ and with an LNr within the 
range from the current vaiue of LVs to *X’ included, ELLC link stations do 
not reset the timer recovery condition. The received LNr may be used to 
update LVs. 
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When ‘Y’ is equal to LN2, ELLC link stations initiate a resetting procedure 
as described in “LLC Rejection Conditions” on page M-22 The value of 
LN2 is a system parameter (see “Maximum Number of LPDU Trans- 
missions - (LN2)” on page M-24). 


M.6.3.9 Link Resetting Procedures 
The resetting procedures described here are used, only on link con- 
nections perceived by the ELLC link station to be in the information 
transfer phase, to (re)-initialize both directions of information transfer. 


e Local Reset 


ELLC link stations indicate a resetting of the link by transferring an 
LSABME command LPDU across the link connection. Upon 
receipt of an LSABME command, ELLC link stations prepared to 
resume normal operation of the link, transfer an LUA response at 
the earliest opportunity, and set LVs and LVr equal to ‘0’. This 
also clears link station busy conditions, if present. Prior to initi- 
ating this link resetting procedure, ELLC link stations may initiate 
a link disconnection procedure as described in “Remote Reset” 
below. 


° Remote Reset 


Under certain rejection conditions listed in “LLC Rejection 
Conditions” on page M-22, ELLC link stations may request the 
adjacent link station to reset the link by transferring an LPDUR 
response. | 


After transmitting an LPDUR response, originating ELLC link 
stations enter the link rejection condition. The link rejection condi- 
tion is cleared when the ELLC link station receives an LSABME or 
an LDISC command or an LDM response from the communicating 
link station in the adjacent node. Other LPDU commands received 
while in the link rejection condition cause receiving ELLC link 
stations to retransmit the LPDUR response with the same informa- 
tion field originally transferred. 


Upon receipt of an LPDUR response, ELLC link stations prepared 
to resume normal operation of the link transfer an LSABME 
command LPDU with ‘P = 1’ across the link connection and start 
LLC Reply Timer, LT1. Otherwise, ELLC link stations initiate the 
link disconnection procedure described in “Link Disconnection” on 
page M-16; or, cause a clearing or resetting of the underlying 
virtual circuit. 


ELLC link stations may start LLC Reply Timer, LT1, on transferring 
the LPDUR response. If LLC Reply Timer, LT1, then expires prior 
to the receipt of an LSABME or a LDISC command from the com- 
municating link station in the adjacent node, ELLC link stations 
may retransmit the LPDUR response and restart LLC Reply Timer, 
LT1. Following transmission of the LPDUR response LN2 times 
ELLC link stations may reset the link as described in “Local 
Reset” above. The value of LN2 is defined in “Maximum Number 
of LPDU Transmissions - (LN2)” on page M-24. 
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M.6.3.10 LLC Rejection Conditions 
ELLC link stations may initiate a resetting procedure as described in “Link 
Resetting Procedures” on page M-21 upon receipt, during the information 
‘transfer phase, of an LPDU with the correct PDUCS, and with one of the 
following conditions: 


e the LPDU is unknown as a command or as a response; 
« the LPDU does not conform to one of the valid formats: 
e the LPDU information field is invalid; or, 


e the LPDU contains an invalid LNr as defined in 
“LLC Protocol Data_Unit_ Reject (L_PDUR) Response” on 
page M-10. 


Coding of the information field of LPDUR responses transferred is given in 
“LLC Protocol Data_Unit Reject (LPDUR) Response” on page M-10. 


Unsolicited LDM - ELLC link stations initiate a resetting procedure as 
described in “Link Resetting Procedures” on page M-21 upon receipt, 
during the information transfer phase, of an LDM response or an LPDUR 
response. 


Unsolicited Response - ELLC link stations may initiate a resetting proce- 
dure as described in “Link Resetting Procedures” on page M-21 upon 
receipt, during the information transfer phase an LUA response or an 
unsolicited LPDU response with ‘F = 1’. 


M.6.4 Link Connection Procedures 


M.6.4.1 Initial Connection Establishment 
The ELLC protocols employ the X.25 call set-up procedures described in 
Chapter 8, “Logical Link Control (LLC) on SNA-to-SNA Connections” on 
page 8-1 for initial establishment of link connections. 


M.6.4.2 Connection Recovery 
Procedures are described to allow recovery from certain link connection 
failures, indicated by PSDNs, to be attempted at the LLC layer when ELLC 
has been selected. Link failures reported by PSDNS in 
CLEAR_INDICATION, RESET INDICATION and RESTART_INDICATION 
packets with the network generated Cause Codes (other than the 
DTE-Generated codes x'00’ and x'80’) are assumed to be temporary in 
nature and, therefore, potentially recoverable. 


e Clears 


ELLC link stations attempt to re-establish virtual calls (switched 
virtual circuits) cleared by PSDNs via CLEAR_INDICATION packets 
that carry recoverable Cause Codes (other than the 
DTE-Generated codes x‘00’ and x‘80’) up to LN2 times at intervals 
of duration LTr before indicating link/station INOP to the higher 
layers of SNA. Connection recovery is initiated by transferring a 
CALL REQUEST packet across the access channel, as depicted in 
Figure M-6 on page M-26(5), indicating: 


— LLC recovery mode: 
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— connection recovery request; and, 
— connection identification information, if required. 


Upon receipt of an INCOMING CALL packet on a logical channel 
associated with a link connection perceived to have a connection 
recovery pending, ELLC link stations cause a clearing of the 
incoming call by transferring a CLEAR REQUEST packet with the 
Cause Code x‘00’, ‘DTE Generated’, and the diagnostic code x‘5C’, 
‘Logical Channel Reserved’. 


Resets 


ELLC link stations only need to log network initiated resets, of 
switched or permanent virtual circuits indicated by PSDNs via 
RESET INDICATION packets that carry recoverable Cause Codes 
(other than the DTE-Generated codes, x‘00’ and x‘80’,) for future 
problem determination purposes. Specific recovery action is not 
required in such instances since ELLC LPDU sequence numbering, 
acknowledgment and re-transmission procedures provide ade- 
qucte data integrity mechanisms to cope with temporary failures 
of this type. 


Restarts 


ELLC link stations treat network initiated restarts, of the X.25 
DTE/DCE interface indicated by PSDNs via RESTART_INDICATION 
packets that carry potentially recoverable Cause Codes (other 
than the DTE-Generated codes, x‘00’ and x‘80’,) as a simultaneous 
clearing of all virtual calls and a resetting of all permanent virtual 
circuits at the X.25 DTE/DCE interface. 


M.6.5 List of LLC Parameters 


The LLC parameters are as follows: 


M.6.5.1 LLC Time-Out_Function - (LFt) 
The duration of the LLC time-out function (LFt) is: 


where: 


LFt = (LT1eLN2+LTd)@LNd 


LT1 is a function of the time allowed by link stations between the 
transmission of commands and receipt of the corresponding 
acknowledgment. 


Upon expiration of timer LT1, Link stations retransmit the 
unacknowledged command with 'P = 1' and restart timer LT1. 


LN2 = '1' is the maximum number of transmissions and retransmissions 
of a LPDU following the expiration of LLC Reply Timer, LT1. 


LTd is typically many times greater than LT1 and is the time to be 
delayed between consecutive repetitions of LT1eLN2. 


LNd = '1l' is the maximum number of repetitions of LT1®LN2+LTd to be 
performed before declaring the logical link connection inoperative. 


Appendix M. Description of the Enhanced Logical Link Control - (ELLC) Procedures M-23 


Although LTd may be defined as zero, experience suggests that when 
LTd='0' and LNd='1' are used, link connections may often be declared 

_ jnoperative prematurely, resulting in unnecessary session outages due to 
momentary network service disruptions. 


lt is, therefore, essential that LT1, LN2, LTd and LNd have default values 
that can be overridden by customers as experience indicates. 


ELLC link stations start LLC Reply Timer, LT1, upon completion of trans- 
mission of IPDUs or SPDU and UPDU commands with ‘P = 1’. 


M.6.5.2 LRNR Query Time-out - (LTn) 
LTn is equivalent to, and may in fact employ the same timer as, LLC 
Reply Time-out, LT1. 


M.6.5.3 LLC Time-Limit - (LT2) 

7 Time-limit LT2 is the maximum time allowed between receipt of a 
command LPDU from the link station in the adjacent node and trans- 
mission of an appropriate response LPDU. This value is product and con- 
figuration specific. LT2 must never exceed the time needed to transmit 
one maximum length frame plus fifty (50) milliseconds. 


The duration of Time-limit LT2 is an LLC parameter that is determined by 
bilateral agreement between communicating link stations. 


M.6.5.4 Maximum Number of LPDU Transmissions - (LN2) 
The maximum number of transmissions and retransmissions of a given 
LPDU following the expiration of LLC Reply Timer, LT1, is a LLC param- 
eter (LN2) whose value is determined by bilateral agreement between 
adjacent link stations. 


Note: 


To facilitate throughput enhancement in environments where the 
quality of service exhibited by underlying network services afford 
adequate data integrity support-of the retransmission recovery 

function may be bypassed when the value of LN2 is equal to one 


(4). 
M.6.5.5 Maximum Number of Bytes in an IPDU - (LN1) 


The maximum permissible number of octets (bytes) in an IPDU is an LLC 
parameter (LN1) which depends upon the maximum length of the informa- 
tion fields transferred across the link connection. 


M.6.5.6 Maximum Number of Outstanding IPDUs - (Lk) 
The maximum permissible number (Lk) of sequentially numbered IPDUs 
that link stations may have outstanding (i.e., unacknowledged) at any 
given time is an LLC parameter which can never exceed one hundred 
twenty-seven (127). The value of ‘Lk’ is determined by bilateral agree- 
ment between adjacent link stations. It is recommended that ‘Lk’ be a 
parameter whose default value can be overridden. 
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M.6.5.7 Link Idle Timer - (LTi) 
The period of time that a link station may allow the link connection to 
remain in the idle state (see “Link Channel States” on page M-5) before, 
initiating a procedure to protect against half-open link connections by, 
a transmitting an LRR command LPDU. LTi is many times greater than LT1. 


+ M.6.5.8 Retry Interval Timer (LTr) 

The period of time that a link station waits, after receipt of lower layer 
service interruption signals, before attempting to re-establish the effected 
connection. The duration of Retry Interval Timer LTr should be randomly 
variable from ‘n’ to (‘n’ + 60) seconds. 


+++4+4 


M.7 LPDU Flow Examples 


' Sample ELLC LPDU flows depicting initial link establishment, initialization, 
information exchange, recoverable call clearing and connection recovery 
are shown in Figure M-6 on page M-26. 


Appendix M. Description of the Enhanced Logical Link Control - (ELLC) Procedures M-25 


++ 
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Figure M-6. ELLC Protocol Data Unit Flows | 


The following notes are keyed to Figure M-6. 


1. initial Connection Initiation - 
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Legend: 
cc: Clearing Cause code 
cid: Connection Identifier — 
Cr: Connection Recovery Indication. 
d: Diagnostic code | OO 
e: ELLC protocol identifier 
Ic: Information command 
iC: Initial Connection indication — 
LS(i): Link Station 'i' 
nul: Null 
SM:  SABME Unnumbered command 
UA: Unnumbered Acknowledgement response 


Link connection establishment is initiated by the transfer of a 
CALL REQUEST packet, to the network access DCE, with the fol- 
lowing parameters in the CUD field: 


e (iC) - Initial connection indicator 
e (e) - Extended LLC protocol indicator 
e (cid) - Connection identifier (optional) 


2. Link Initialization 


Link initialization is initiated by the transfer of a DTE_DATA packet 
containing an LSABME command LPDU in the user data field and 
may be terminated either by the receipt of an LUA command 
LPDU or receipt of an LUA command LPDU followed by an 
exchange of DTE DATA packets containing LRR command and 
response LPDUs, respectively. 


3. Information Exchange 


Information is exchanged between adjacent link stations by the 
trarsfer of DATA packets or packet sequences with the user data 
field containing an information command LPDU. 


4. Network Initiated Call Clearing 


Network initiated call clearing is signalled by the transfer of unso- 
licited CLEAR_INDICATION packets to both the calling and called 
link stations containing: 


e (cc) - Cause Codes in the Clearing Cause field. 
e (d)- Diagnostic Code in the Diagnostic Code field. 


Retry Interval Timer LTr duration between Network Call Clearing 
and Connection Recovery. 


5. Connection Recovery 


Link connection recovery, following a recoverable network initiated 
call clearing is initiated by the transfer of a CALL REQUEST 
packet, to the network access node, with the following parameters 
in the CUD field: 


° (Cr) - Connection Recovery indication 
° (e) - Enhanced LLC protocol indicator 
e (cid) - Connection identifier (optional) 


6. Link Initialization/Assurance 


Link re-initialization is accomplished by an exchange of LRR 
command and response LPDUs, respectively. | 


7. Continue Information Exchange 
Proceeds as in item 3. above. 
8. Connection Termination 


Termination of a link connection is initiated by the transfer of a 
CLEAR_REQUEST packet, to the network access node, containing 
the following parameters: 


e (cc) - Clearing Cause Code; and, 


e (d) - Diagnostic Code. 
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M.8 LINK STATION FINITE STATE MACHINES 


M.8.1 Chart Description 
| Operation of the ELLC protocol for link stations is formalized by the charts 
- contained in “Link Station States and Actions” on page M-36 for the link 

connection states defined in “ELLC STATE DESCRIPTIONS” on page M-29. 
Action(s) taken by link station{s) as a result of particular stimuli are shown 
at the intersection of the various link connection states and the stimulus. 
ELLC link connection states include the predicate conditions defined in 
“PREDICATES” on page M-30 and the state variables defined in “State 
Variables” on page M-31, either or both of which are indicated under the 
heading{s) ‘P: V:’ (when appropriate) in the charts in “Link Station States 
and Actions” on page M-36. ELLC stimuli include the events as well as 
the command and response LPDUs defined in “ELLC Stimuli” on 
page M-32. 


Information contained at these intersections specify the action(s) taken 
(denoted by two uppercase letters ‘LL’), the basic procedure executed 
(denoted by the small letters ‘bp’ concatenated with an upper case letter 
‘L’), the PDU(s) transferred (if any), signified by the protocol data unit 
identifier enclosed in brackets with any required parameters 
[PDU_id(p1,..,on)] and the new state of the link connection to be entered 
(if any). 


The PDU transferred, [PDU], may be any of the LLC command or 
response LPDUs listed in “Commands Sent and Received” on page M-32 
and “Responses Sent and Received” on page M-33 and a small letter ‘c’ 
or ‘r’ may be appended signifying command or response, respectively; or 
the LPDU indicated by the PDU output scheduling algorithm signified by 
an undefined protocol machine [PDU_Out_UPM]. XPo, TPo and LPo 
signify the output PDU indicated by execution of the basic procedures X, T 
and L, respectively. Additional appendages that specify the value of the 
P-bit for command LPDUs and the F-bit for response LPDUs when neces- 
sary, include: 


¢ ° - signifying a P/F-bit value of ‘0’; 

¢ | - signifying a P/F-bit value of ‘1’; 

¢ ” ~ signifying a P/F-bit value equal to the value of the variable, Vf; 
and 

¢ ’- signifying an F-bit value equal to the value of the P-bit in the 
received command LPDU to which it responds. 


In the event the PDU transferred causes a packet layer clearing or reset- 
ting of the underlying virtual circuit, an appropriate diagnostic code is 
included {see Appendix H, “DTE-Generated Diagnostic Codes” on 

page H-1 for DTE Generated Diagnostic codes used when the virtual 
circuit for SNA-to-SNA connections are cleared or reset; or the DTE/DCE 
interface is restarted). When no [PDU] is indicated, nothing is transferred 
across the link connection to the link station in the adjacent node as the 
result of that particular stimulus. 


Applicable ELLC link connection state transitions are specified under the 


heading ‘New State’ when the link connection is to be placed in a different 
state following the specified action(s) and/or PDU transfer(s). Link con- 
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nections remain in the current state when no new state to be entered is 
specified at a particular intersection. 


Alternative procedures, denoted by lower case letters ‘I’ or the word ‘or’ 
under the ‘ALT’ heading, are specified where appropriate. 


References to clarifying notes (denoted by ‘#n’ (where ‘n’ is a decimal 
integer) under the ‘ALT’ heading) are also provided at certain inter- 
sections, where deemed prudent, to denote extenuating circumstances 
considered essential to proper operation of the protocol, including: 


e When an exchange of link station identification information ts not 
required prior to link set-up. 


¢ The virtual call (switched virtual circuit) supporting the link con- 
nection is cleared (e.g., CLEAR REQUEST or CLEAR_INDICATION) 
the underlying virtual circuit is terminated and the link connection 
placed in the INOPERATIVE state. 


The sample sequences shown in Figure M-6 on page M-26 represent one 
example of how the tables may be used. 


M.8.1.1 ELLC STATE DESCRIPTIONS 
INOPERATIVE: The link station, not having resources allocated sufficient 
to support link connection, is non-functional and reacts positively only to 
link activation stimulus as specified in “INOPERATIVE State” on 
page M-36 


LINK_CLOSED: The link station, having sufficient resources to support 
link connection allocated, reacts to stimuli as specified in “LINK CLOSED 
State” on page M-37 when authorized and prepared to support link initial- 
ization. 


LINK_OPENING: Link stations having initiated the link set-up procedure, 
by transferring an SABME command LPDU across the link connection, 
react to stimuli as specified in “LINK OPENING State” on page M-39 
pending receipt of link set-up confirmation (UA response LPDU) from the 
link station in the adjacent node. 


LINK_CLOSING: Link stations having initiated the link disconnection pro- 
cedure, by transferring a DISC command LPDU across the link connection, 
react to stimuli as specified in “ LINK CLOSING State” on page M-41. 


LINK_OPENED: Link stations having completed the link set-up procedure 
react to stimuli as specified in “LINK OPENED State” on page M-42 in the 
absence of error or exception condition(s) effecting the associated link 
connection. 


CHECKPOINTING: Link stations having transferred an S-format command 
LPDU with ‘P=1’ across the link connection as a result of the expiration of 
LLC Reply Timer LT1, on the associated link connection react to stimuli as 
specified in “CHECKPOINTING State” on page M-46. 


LINK_RESETING: Link stations having received an SABME command 


LPDU from the link station in the adjacent node, initiating the link resetting 
procedure, react to stimuli as specified in “LINK RESETING State” on 


Appendix M. Description of the Enhanced Logical Link Control - (ELLC) Procedures M-29 


_ page M-53 until the resetting procedure is completed by the transfer of 
either a UA or DM response LPDU as directed by a higher layer function. 


LINK_RECOVERY: Link stations having received a FRMR response LPDU 
from, or transferred a FRMR response LPDU to, the link station in the 
adjacent node react to stimuli as specified in “LINK RECOVERY State” on 
page M-55 until a resetting procedure is completed for the link con- 
nection. — | 


M.8.1.2 PREDICATES 


ELLC predicate conditions include: 


P: 
which signifies general condition(s) for the link connection and may 
take on the values: 

e ‘Nul’ - signifying that no outstanding exceptional general condi- 
tions exists for the link connection. 

e ‘RJN’ - signifying that an out-of-sequence IPDU has resulted in the 
transfer of an REJ command or response LPDU to the link station 
in the adjacent node. 

Pb Busy: 


Signifies condition(s) for the link relative to resource constraints that 
temporarily prevent acceptance of I-format LPDU(s): 


¢ ‘B’ by both the local link station and its communicating partner in 
the adjacent node; 


¢ ‘L’ by the local link station; 


e ‘N’ by neither the local nor its communicating partner in the adja- 
cent node; or, 


e ‘R’ by the link station in the adjacent node. 


Pc_Pending Command 


Identifies the pending command LPDU when a command transmission 
is awaiting completion of a checkpointing cycle, and may take on the 
values: 


e ‘D’ signifying a Disconnect command; 

e ‘R’ signifying a Receive Ready command; 
¢ ‘T’ signifying a Test command; 

° 'X’ signifying an Exchange_Identification; or 


e ‘N’ signifying that no command LPDU is pending. 


Pr_Recovery.Status 
e ‘Nul’ signifying no recovery procedure in process; 


¢ ‘L’ signifying recovery due to a locally detected PDU_Rejection 
condition in process; or, . 
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e ‘R’ signifying recovery due to a remotely detected PDU_ Rejection 
condition in process. 


Pt_TEST.Status 
e ‘Nul’ signifying that no TEST of the link connection is in process; 


e ‘I’ signifying that an incoming TEST response LPDU from the link 
station in the adjacent node is pending; 


¢ ‘QO’ signifying that an outgoing TEST response LPDU to the link 
station in the adjacent node is pending; 


e ‘10’ signifying that an incoming TEST response LPDU from and an 
outgoing TEST response LPDU to the link station in the adjacent 
node are both pending. 

Px_XID.Status 


° ‘Nul signifying that no exchange of identification information (XID) 
is ir process; 


ef signifying that an incoming XID response LPDU from the link 
station in the adjacent node is pending; 


e ‘QO’ signifying that an outgoing XID response LPDU to the link 
station in the adjacent node is pending; | 


e ‘lO’ signifying that an incoming XID response LPDU from and an 
outgoing XID response LPDU to the link station in the adjacent 
node are both pending. 


M.8.1.3 State Variables 
ELLC state variables include: 


Va - Acknowledged LPDU: containing the last Nr value received, or ‘0’ 
immediately following completion of the link set-up procedure; 


Vf - Final Bit Value: containing the value for a final bit pending trans- 
mission (e.g., associated P-bit value received). 
Vi - Initialization Status: 
Signifies link initialization progress and may take on the values: 

e ‘L’ signifying locally initiated link set-up; 

¢ ‘R’ signifying remotely initiated link set-up; 

e ‘B’ signifying locally and remotely initiated link set-up; 

¢ ‘P’ signifying initialization confirmation pending; or, 

° ‘Nul’ signifying initialization completed/not started. 
Vr - Next IPDU In: denoting the sequence number (Ns) of the next in- 


sequence I-format LPDU to be received across the link connection from 
the link station in the adjacent node. 


Vs - Next IPDU Out: denoting the sequence number (Ns) of the next in- 


sequence I-format LPDU to be transferred across the link connection to 
the link station in the adjacent node. 
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M.8.1.4 ELLC Stimuli 
ELLC protocol stimuli include the events, commands and responses 
described in the following paragraphs. 


Events 


e L3RDY - PACKET LAYER (Layer 3) READY: representing a signal 
from the X.25 Packet Layer (layer 3) that the underlying virtual 
circuit, in the READY (p4 or d1) state, is prepared to support a link 
connection. | 


e LSTRT - LINK START: representing a higher layer stimulus to 
establish a link connection to a communicating link station in the 
adjacent node. 


e LSTOP - LINK STOP: representing a higher layer stimulus to ter- 
minate the link connection to the communicating link station in the 
adjacent node. 


e L3NOP - LAYER_3 _ INOPERATIVE: representing a signal from the 
X.25 Packet Layer (layer 3) that the underlying virtual circuit, in the 
INOPERATIVE state, is no longer capable of supporting a link con- 
nection. 


¢ ELBSY - ENTER LOCAL BUSY: representing a signal from the 
DLC.X25 Manager informing the link station of a local resource 
constraint that temporarily prohibits the continued acceptance of 
l-format LPDUs. | 


e XLBSY - EXIT LOCAL BUSY: representing a signal from the 
DLC.X25 Manager informing the link station of the removal of an > 
existing local resource constraint. 


e ELPDU - ERRONEOUS _LLC PROTOCOL_DATA_UNIT: repres- 
enting receipt of an erroneous LPDU (e.g., one containing an uni- 
dentifiable LLC command or response, | field too long, etc.) on the 
link connection. | 


¢ XCHID - EXHCANGE_ IDENTIFICATION: representing a higher layer 
request/authorization to transfer LLC link station identification 
information. 


e LTES™ - LINK_TEST: representing a higher layer 
request/authorization to transfer LLC link test data. 


¢ SDATA - SEND DATA: representing a higher layer request for the 
transfer of user data to the link station in the adjacent node. - 


e ELT1X - ELLC_LINK_REPLY_ TIMEOUT EXPIRATION: representing 
expiration of the LLC link reply timeout, Timer LT1. 


e ELTiX -ELLC LINK_IDLE_TIMEOUT EXPIRATION: representing 
expiration of LLC link query timeout, Timer LTi. 
Commands Sent and Received 


e LI -I-format LPDU: representing a DATA packet or packet 
sequence containing an |-format LPDU in the user data field(s). 
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e LSM -LLC SET MQDE (LSABME): representing a DATA packet 
containing a Set_ Mode command LPDU (LSM) in the user data 
field. 


e LDC - LLC DISCONNECT (LDISC): representing a DATA packet 
containing a Disconnect command LPDU (LDC) in the user data 
field. 


e LXC - LLC EXCHANGE IDENTIFICATION: representing a DATA 
packet or packet sequence containing an Exchange Identification 
command LPDU (LXC) in the user data field(s). 


e LTC -LLC LOGICAL _LINK_TEST: representing a DATA packet or 
packet sequence containing a Link Test command LPDU (LTC) in 
the user data field(s). 


e LRR- LLC RECEIVE READY: representing a DATA packet con- 
taining a Receive Ready command LPDU (LRR) in the user data 
field. 


Responses Sent and Received 


e LDM-LLC DISCONNECTED MODE: representing a DATA packet 
containing a Disconnected Mode response LPDU (LDM) in the 
user data field. 


e LPR-LLC PDU REJECT: representing a DATA packet containing 
a PDU_Reject response LPDU (LPR) in the user data field. 


e LUA-LLC UNNUMBERED ACKNOWLEDGE: representing a DATA 
packet containing an Unnumbered_ Acknowledge response LPDU 
(LUA) in the user data field. | 


e LXR-LLC EXCHANGE IDENTIFICATION: representing a DATA 
packet or packet sequence containing an Exchange _ Identification 
response LPDU (LXID), including link station identification informa- 
tion, in the user data field(s). 


e LTR-LLC TEST: representing a DATA packet or packet sequence 
containing a Link_Test response LPDU (LTR), including test data, 
in the user data field(s). 


e LRR - RECEIVE READY: representing a DATA packet containing a 
Receive Ready response LPDU (LRR) in the user data field. 


M.8.1.5 BASIC PROCEDURES 
Basic procedures defined for ELLC link stations, specified at the inter- 
section of a state/condition/option and a stimulus, denoted by a small 
letter ‘bp’ concatenated with a capital letter ‘L’ (bpL), include: 


bpA - Acknowledgment 


Process the received Nr value according to the procedure specified by 
CHART A in “Acknowledgment” on page M-57 and if Va<Nr<Vs: 
Va=Nr, RT1; Va<Nr=Vs : Va=Nr, TT1, ITi; ELSE ; NS. 


bpL - Limit 


Perform the procedure specified by CHART L in “Limit” on page M-57 
which increments the (re)-transmission count ‘Ct’ by one, then if 
Ct=N2 : report the failing procedure to, and await further direction 
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M.8.1.6 Actions 


from, a higher layer of SNA; Else : retry the indicated protocol proce- 
dure. 


bpR - Rejection 
Process the received REJECT command/response LPDU according to 
the procedure specified by CHART _R in “Rejection” on page M-57 
and if Va<Nr<Vs : Va=Vs=Nr, RT1; Va<Nr=Vs : Va=Vs=Nr, TT1, 
ITi; ELSE : Vs =Nr. 

bpT - TEST 


Perform the procedure specified by CHART_T in “Link Test” on 
page M-57 with the result that if Pt=Nul : Pt=Ip, TTi, RT1, Ct=‘0’, 
[LTC*]; Pt=Rp : IH, Pt=Nul, [LTR(F=Vf,id)]; Pt=IRp : IH, Pt=Ip, 
[LTR(F =Vf,id)]; Else : LE. 

bpX - EXCHANGE_IDENTIFICATION 


Perform tre procedure specified by CHART X in “Exchange 
Identification” on page M-58 with the result that if Px=Nul : Px=Ip, 
TTi, RT1, Ct=‘0’, [LXC’]; Px=Rp : 1H, Px=Nul, [LXR(F =Vf,id) J; 
Px=IRp : 1H, Px=Ip, [LXR(F =Vf,id)]; Else : LE. 


Actions taken by ELLC link stations, denoted at the intersection of a 
State/condition/option and a stimulus, are identified by two capital letters 
‘LL’ which are defined as follows: 
DB - Discard BTU 
Discard the contents of the information field of the received PDU and 
take no further action as a result of its receipt. 
DL - Disable Link 
Destroy the link connection, releasing the Access Channel and Media 
Access Port associated with the link appearance. 
EL - Enable Link 
Establish a link connection by associating a specific Access Channel 
and Media Access Port as required to create a link appearance. 
FB - Forward BTU 
Forward the received Basic Transmission Unit to the higher layer 
using protocol entity. 
IH - Inform Higher Layers | 
Inform a higher layer of SNA of the occurrence via internal signalling 
mechanisms. 
IP - Ignore Protocol Data Unit 


Take no action and ignore the received protocol data unit in its 
entirety. 
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ITi - Initiate Query Timer, LTi 


Initiate a logical link timeout for the duration of Query Timer, LTi. 


LE - Local Procedure Error 
Representing an internal signalling error or illogical protocol 
sequence on the part of the ELLC link station that may be either 
ignored or reported to a higher layer of SNA for analysis. 

NA - Not Applicable 
Identifies events/actions/responses that cannot occur for a given 
state/condition/alternative. 

NS - No Specific Action 


No specific action is required by the ELLC link station protocol. 


QL - Queue LPDU 


Place the output BTU in the information field of an Information LPDU, 
place the LPDU on the outbound queue for the associated logical link, 
and pass control to the PDU_ Out_UPM. 


RE - Remote Procedure Error 
Representing a protocol procedure error on the part of the ELLC link 
station in the adjacent node that may be either iqnored or reported to 
a higher layer of SNA for future analysis. 

RS - Report Status 
Report the current status of the ELLC link station to a higher layer of 
SNA. 

SL - Set-Up Link 


Initiate the link set-up procedure described in § 4.5.4.1. 


TC - Terminate Contact 
Terminate the SNA CONTACT phase and signal CONTACTED to a 
higher layer of SNA. 

TL - Terminate Link 


Terminate the link Initialization procedure and transfer an unsolicited 
DISCONNECTED MODE response to inform the link station in the adja- 
cent node. 


TTi - Terminate Timer LTi 


Stop the link idle time-out, LTI. 
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M.8.2 Link Station States and Actions 


M.8.2.1 INOPERATIVE State 


Stimuli Ps: V: “le Action(s) [PDU Transfers] 
nai 
— 
a 
a 


XLBSY 
XCHID : LE | : ; 
LTEST LE | | | 


ELTiX LE | 


CHART 1-I: I-Format LPDUs in INOPERATIVE State 
Stimuli Action(s) [PDU Transfers] New State 
nS: SU UNE 


CHART 1-S: S-format LPDUs in INOPERATIVE State 
Stimuli ALT! Action(s) [PDU Transfers] New State 


CHART 1-U: U-format LPDUs in INOPERATIVE State 


Action(s) [POU Transfers] New State 


LDC|LDM _ 


= ee 
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M.8.2.2 LINK _CLOSED State 
CHART 2-E: EVENTS in LINK CLOSED State 


Stimuli P: V: ALT) Action(s) [PDU Transfers] 


New State 


L3RDY 


LSTRT =ct+ttxNul+ 
iNul 


SL, Vi=L, Ct=0, TTi, RT [LSM] 


LINK OPENING 


LINK OPENING 


(LON? ] 


LSTOP 


L3NOP INOPERATIVE 
| ELBSY  bR 
! ELSE | Pb=L | 
ae | GE Be —_ | 
XCHID bpX - [XPo'] 


ELTIX  Ct<LN2+ 
x1{10 | 


bpL [LTC} (data) ] 


tI] 10 


ELSE 


Nul 


CHART 2-1: I-Format LPDUs in LINK_CLOSED State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] New State 
Lie? IP 
Lict NS [LDM?] 


LIr?|? IP 


CHART 2-S: S-format LPDUs in LINK CLOSED State 


Stimuli Ps: V: ALT} Action(s) [PDU Transfers] 


LRR| LNR|LRJc® 


LRR{LNR|LRJc? [LOM2] 


LRR|LNR| LRIr® | 2 
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CHART 2-U: U-format LPDUs in Received LINK CLOSED State | | 


| 


Stimuli P: Vz ALT} Action(s) | [PDU Transfers] 


LSM = Nul#iNul|R | IH, VisR, Vf=P, IT 


CHART 2-U: U-format LPDUs in LINK CLOSED State (Continued) | 


' 
a 
t 


| Stimuli P: V: ALT! Action(s) [PDU Transfers] New State 
LXC IH, Px=0, Vf=P 
LXR®|2 x] IH, Px=Nul, TTl 
x10 TH, Px-0, 171 
ELSE (RE) 
ie IH, Pt=0, Vf=P 


IH, Pt=Nul, TT1 
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M.8.2.3 LINK_OPENING State 


CHART 3-E: EVENTS in LINK_OPENING State 


Stimuli Ps: Vs ALT} Action(s) [PDU Transfers] New State 
L3RDY LE 
LSTRT LE | 


LSTOP Vi=Nul, TT1, ITi [LDON® ] LINK_CLOSED 


ELBSY  bR 
ELSE 
XLBSY —bB Pb=R 
ELSE Pb=Nul po wees | 


CHART 3-E: EVENTS in LINK_OPENING State (Continued) 


CHART 3-I: I-Format LPDUs in LINK_OPENING State 


Stimuli P: V: ALT| Action(s) [PDU Transfers] New State 


IH, Vi=Nul, FB, RTi [LRRr®]| LINK_OPENED 


[LRRr2]} LINK_OPENED 
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CHART 3-S: S-format LPDUs in LINK_OPENING State 
Stimuli ALT! Action(s) [POU Transfers] New State 


LRR(O) | 
LRJ(O)ct = iP IH, Pb=Nul, Vi=Nul, RTi [LRRr+]} LINK_OPENED 


EESE 


LNR(0)c2 IH, Pb=R, Vi=Nul, RTi [LRRr+]} LINK _OPENED 


ELSE 


CHART 3-U: U-format LPDUs in LINK OPENING State 


Stimuli P: V: ALT Action(s) [PDU Transfers] | New State | 


LSH VieR, TT1, ITi [LUA'] | 


IH, Vi=Nul, TT1l, ITi [LDM']| LINK_CLOSED 
=—h 


IH, Pc=Pt=Px=Va=Vf=Vi=Vr=Vs=Nul, TTi, 
RTi [LRRc#]} CHECKPOINTING 
LDN IH, Vi=Nul, TT1, ITi LINK_CLOSED 


LTR IP_(RE) 


LXR IP_ (RE) 
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M.8.2.4 LINK CLOSING State 


EVENTS in LINK_CLOSING State 


Stimuli P: V: ALT} Action(s) [PDU Transfers] 


LSTOP 
L3NOP INOPERATIVE 


CHART 4-E: 


7 
| LTEST 
LE | 


| SDATA 


| 
| 
ec a eee ee 


CHART 4-1: I-Format LPDUs in LINK CLOSING State 


Stimuli Ps: V: ALT! Action(s) (PDU Transfers] New State 


CHART 4-S: S-format LPDUs in LINK_CLOSING State 


Stimuli ALT| Action(s) [PDU Transfers] 
CT 


U-format LPDUs in LINK_CLOSING State 


New State 


CHART 4-U: 


Stimuli P: V: aLt| action(s) —==—_—[POU Transfers) | New State 
Ce Ce 


pu 
eed 


ae een amet 
Xr 
foe 
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M.8.2.5 LINK_OPENED State 


CHART 5-E: EVENTS in LINK_OPENED State 


Stimuli P: V: ALT) Action(s) [PDU Transfers] | New State 
L3RDY LE | E 
LSTRT | LE Oo ae 
LSTOP This RE Cte (Loct]} LINK CLOSING 
ELBSY bL|B. LE 
RIN+) bR Pb=B See 
ELSE Pb=L rrr 
| XLBSY bo | Pb=Nul, RT1, Ct=0 [LRRc?]} CHECKPOINTING 
| bB | Pb=R, RTL, Ct=0 [LRRc+]} CHECKPOINTING 


RJN+bL | Pb=Nul, TTi, IT1, Ct=0 [LRRc?]| CHECKPOINTING 


RJN+bB Pb=R, TTi, RT1, Ct=0 [LRRc4]} CHECKPOINTING 


ELSE 


CHECKPOINT ING 


Px=I, Ti, RT1, Ct=0 [LXC?] 


x0 | TH, Px=Nul [LXR"] 


xNul 


xIG IH, Px=] [LXR"] 


ELSE LE 


LTEST  tNul CHECKPOINTING 


t/o 


tIo 
ELSE 
SDATA 


ELPDU | 


ELTIX RIN+{bR 


[PDU_Out_UPH] 


LINK_RECOVERY 


TH (RE), TT1, ITi, Pre=L- [LPR®] 


[LRRc+]} CHECKPOINTING 


[LNRc+]) CHECKPOINTING 


[LNRc*}]]| CHECKPOINTING 


IT1, Ct=0 [LRRc*]| CHECKPOINTING 


RIN+bL|B 


bL|B 


ELSE 
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CHART 5-I: I-Format LDPUs in LINK_OPENED State 


Action(s) [PDU Transfers] New State 


bpA, FB, P=Nul [PDU_Out_UPH] 


Stimuli Ps: V: ALT 


Llic{r® RUN 


bL|B 


bR 


RJN+bL|B 


RUN+bR 


ELSE 


Llict RUN bpA, FB, P=Nul [LRRr?] 
bL |B bpA, DB [UNRr] 
RIN+bL  B | bpA, DB, P=Nul [LNRr?] | 


RJN+bR 


ELSE 


LINK RECOVERY 


RIN, bL|B 


RIN+bL |B 


bR 


RJN+bR 


ELSE 


RIN, bL|B 


RIN+bL|B 


bR 


RJN+bR 


bpA, DB, P=RJN [LRJr?] 


IH_ (RE), Va=Vs=Nr, TT1, ITi, Pr=L [LPR®°]| LINK _RECOVERY 


ELSE 


i 
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CHART 5-S: S-format LPDUs in LINK_OPENED State (Continued) 


[PDU Transfers] New State 


LINK RECOVERY 


Stimuli P: V: ALT) Action(s) © 


LRRc| re RUJN+bL 


bL 


RIN+ | bB 


ELSE 


RJN| bL 


RIN+|bB 


ELSE 


RJN+bL 


RJN+bR 


PRoE [LPR°]! LINK RECOVERY 


ELSE 


LNRc|r® RJN+bL 


bNul 


i s 


bL 


LNRc! ~=bNul 
bL 
bB 


LNRr? 


LINK_RECOVERY 


ee os 


IH_ (RE), Pb=R, Va=Vs=Nr, TT1, ITi, Pr=L 
[LPR®°] 


ELSE 


LINK_RECOVERY 


RIN| bL 


bB 


Pb=Nul 


RJN 


RJN+|bL 


RIN+|bB 


ELSE 


LRJr? = bB 
RJN+bR 
LINK_RECOVERY 
ELSE IH (RE), Va=Vs=Nr, TT1, ITi, Pr=L [LPR®]| LINK RECOVERY 
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CHART 5-U: U-format LPDUs in LINK_OPENED State 


Stimuli Ps: Vz: ALT} Action(s) [PDU Transfers] 
LSH IH, Vi=R, Vf=P, TTl, ITi LINK _RESETING 


LDC THe: Tide [LUA']} LINK CLOSED 


LUA IH (RE), TT1, ITi, Pr=b [LPR°] | LINK_RECOVERY 


LDH Thy Th ah LINK_CLOSED 
LPR IH, TT1, ITi, Ct=0, Pr=R | LINK_RECOVERY 


LXC IH, Px=0, Vf=P 

LXR IH (RE), Px=Nul, TT1, ITi, Pr=R [LPR] LINK RECOVERY 
LTC TH, Pt=0, Vf=P | 

LTR | TH (RE), Pt=Nul, TT1, ITi, Pr=R [LPR]; LINK_RECOVERY | 
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M.8.2.6 CHECKPOINTING State 


CHART 6-E: EVENTS in CHECKPOINTING State =i(‘<i=;‘<i<S~;S”*#*<‘*d State 


cNul+ 
tNul 
t0 

tIo 


LTEST 


Pc=T 
Hy Pt=Nul [LTR"] 


ELSE 


SDATA [PDU_Out_UPH] 
ELPDU IH_ (RE), TT1, ITi, Pre=L- [LPR°]} LINK_RECOVERY 


t|x0 


| Action(s) [PDU Transfers] 
LSTRT LE 
LSTOP = cNul 
RIN+cR 
ELSE 
Pen! 
ELBSY  RJN+|cR Ph=L, Pc=Nul 
| RJN+/bR | Pb=B, fut hh mr | 
: bLiB Le ; 
ELSE Pb=L eee | 
XLBSY — RJN+|bL IH, Ph=Nul, Pc=R [LRRr®] 
ELSE LE eee 
Pc=X 
IH, Px=Nul | [LXR"] 
IH, Px=] [LXR"] 
La RECOVERY 


t+x7#0 Ce=Cttl 
Ct=LN2 IH, IT1, IV LINK_CLOSED 


t+xNul 


x0| 10+ 
Ct<LN2 


tO| 10+ 
Ct<LN2 [LTC (data)] 
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CHART 6-I: I-Format LPDUs in CHECKPOINTING State 


Stimuli P: V: ALT! Action(s) [PDU Transfers] 


Llic|r® RJN+cR+ 


a<Vs P=Pc=Nul, FB [LRRr®] 
a<NrsVs! P=Pc=Nul, Va=Nr, FB [LRRr®] 
cRt 

a<Vs Pe=Nul, FB [LRRr®] 

a<NrsVs | Pc=Nul, Va=Nr, FB [LRRr® ] 

bL+a<Vs DB [LNRr® ] 

a<NrsVs | Va=Nr, DB [LNRr®] 

BON IRON iL 2 ear as fe tenga ieee 

a<Vs P=Nul, FB [LRRr®] 
a<NrsVs | Va=Nr, P=Nul, FB cLRRr®) | | 
: ELSE Hk ee ee ee 1 | 
! acVs FB [LRRr®] | | 


a<NrsVs 


RJNtcR+t 
a<Vs 


cR+ 
a<V5 Po=Hul, Fb [LRRi** | 
a<NrsVs | Pc=Nul, Va=Nr, FB [LRRr? ] 
bL+aNr<Vs DB [LNRr?] 
a<NrsVs | Va=Nr, DB [LNRr? ] 
RIN|RUN+bL | -- --- - lalla 
a<Vs P=Nul, FB [LRRr? ] 
a<NrsVs | Va=Nr, P=Nul, FB [LRRr?] 
ELSE sf} > 7 - - - ee - -- 
a<Vs FB [LRRr? ] 
a<NrsVs | Va=Nr, FB [LRRr? ] 
Llir IP_(RE) 
Llec|r® cRta<Vs Pce=Nul, DB, P=RUN [LRJr®] 
a<Nr<sVs | Pc=Nul, Va=Nr, DB, P=RJN [LRJr®] 
RINtcRt =f} --------------- HH 
a<Vs Pc=Nul, DB, P=RJN 


a<NrsVs | Pc=Nul, Va=Nr, DB, P=RJN 


bL+a<Vs DB, P=RJN [LNRr?] 
a<NrsVs | Va=Nr, DB, P=RJN [LNRr® ] 

RON RONAN Latte tS lS ce ahah ie eae ee ier ee 
a<Vs DB 


a<Nr<sVs | Va=Nr, DB 


1S) SO ee a ea 
a<Vs DB, P=RJN [LRJr®] 
a<NrsVs | Va=Nr, DB, P=RUN [LRJre] 
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CHART 6-1: 


I-Format LPDUs in CHECKPOINTING State (Continued) 


Stimuli Ps: V: ALT} Action(s) [PDU Transfers] 


LIec! 


LIert 
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cR+a<Vs 


a<NrsVs 
RUJN+cR+ 
a<Vs 


a<NrsVs 
bL+a<Vs 

a<NrsVs 
RJN+ 

a<Vs 

a<NrsVs 
RJN+bL+ 

a<Vs 

a<NrsVs 
ELSE 


a<Vs 


a<Nr<Vs 


Pc=Nul, DB, P=RJN 


ee a nn ee ed 


ee 


Va=Nr, DB, P=RJN 


IP_(RE) 


[LRJr?] 


eee 


eee 


[LRIr?] 


CHART 6-S: S-format LPDUs in CHECKPOINTING State 
Stimuli P: V: ALT] Action(s) [PDU Transfers] 


LRRc| r° cR 

RIN+| bL+ S22 eee eS Se ee lS SS 
a<Vs 
a<NrsVs 

RINMRECRE bw Re Se See eS ee ee Se ee eS eee 
a<Vs , Pb=h 
a<NreVs | IH, Pb=Nul, Va=Nr 

(4 Sea ee Na ee ee 
a<Vs 
a<NrsVs 


RIN+! bL+ 
a<Vs [LNRr?] 
a<NrsVs 

RINtHReCRE (EH He Se Se See See Se Se ee eee Ses 
a<Vs 


asNrsVs | IH, Pb=Nul, Va=Nr 
ELSE (awl Pp RH He ee ee eS ee ee ee eS 
a<Vs 


ee 


a<NrsVs 


LRRr? = cR Va=Nr [LRRc? ] 
RIN+! bl + -~------------------- 
a<Vs LINK_OPENED 


a<NrsVs LINK_OPENED 
RINtbRtcR+ f- — —- -- - - - - - - ee eH eH ee ee 
a<Vs 


a<NrsVs | IH, Pb=Nul, Va=Nr 
EESE 9 5 eee ee ee eee ee 
a<Vs LINK_OPENED 


a<NrsVs LINK_OPENED 
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CHAR? 6-S: S-format LPDUs in CHECKPOINTING State (Continued) 


Stimuli P: V: ALT| Action(s) [PDU Transfers] New State 
LNRc|r® bNultcR IH, Pb=R, Va=Nr 
bL+cR IH, Pb=B, Va=Nr 
RJN+cR IH, Pb=R, Va=Nr 
RJN+bL+ 
a<Vs IH, Pb=B 
a<NrsVs | IH, Pb=B, Va=Nr 
RIN+ ~------+------------ 
a<Vs IH, Pb=R ae 
a<NrsVs | IH, Pb=R, Va=Nr 
ELSE sf} -- -- - - - - ------------- | 
a<Vs NS 


a<NrsVs | Va=Nr | | 


| ; 
LNRc! bNul+cR IH, Pb=R, Va=Nr [LRRr?] | 
bL+cR IH, Pb=B, Va=Nr [LNRr?] 
Lf MR ec a a a 
a<Vs IH, Pb=B [LNRr?] 
a<NrsVs | IH, Pb=B, Va=Nr [LNRr2 ] 
RIN|RUN#CR+> — —- - ----- ae -- 
a<Vs IH, Pb=R [LRRr? ] 
a<NrsVs | IH, Pb=R, Va=Nr [LRRr? ] 
PRR UE eta evens Tee cet OS Soe ae ee See eS ae 
a<Vs NS [LRRr?] 
a<NrsVs | IH, Va=Nr (LRRr?] 
ELSE Pe Ne eA ae at ee a ae ER Se ee leresericnn J 
a<Vs NS [LRRr? ] 
a<NrsVs | Va=Nr [LRRr? ] 


LNRr? =bNul+cR TH, Pb=R, Va=Nr [LRRc?] 


bL+cR IH, Pb=B, Va=Nr [LNRc?] 
RUJN+cR IH, Pb=R, Va=Nr [LNRc?] 
fi) am a a aR 
a<V.. IH, Pb=B LINK_OPENED 
a<NrsVs | IH, Pb=B, Va=Nr LINK_OPENED 
RIN¢ 29 be - eee eH eee ee EE ee ie a 
a<Vs IH, Pb=R LINK_OPENED 
a<NrsVs | IH, Pb=R, Va=Nr LINK_OPENED 
1S) re 
a<Vs NS LINK_OPENED 


a<NrsVs | Va=Nr LINK_OPENED 
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CHART 6-S: S-format LPDUs in CHECKPOINTING State (Continued) 


Stimuli P: V: ALT! Action(s) [PDU Transfers] New State 


LRJc|r® cR+RIN+bL | Va=Nr 


bL+a<Vs NS 


a<NrsVs | Va=Nr 


RINtDRtCRt | — ------------------- 
a<Vs IH, Pb=Nul 
a<NrsVs | IH, Pb=Nul, Va=Nr 
ELSE ~------------------- 
a<Vs NS 
a<NrsVs | Va=Nr 
LRJc! cRtaNR<Vs IH ELRRr?] 
asVs Va=Nr [LRRr!] | | 
RJN+bL Va=Nr [LNRr2 ] | 
bL+a<Vs NS [LNRr? ] 
a<NrsVs | Va=Nr [LNRr?] 
RINtcRt of -------+~--+~-----~---- 
a<Vs NS [LRRr?] 
a<NrsVs | Va=Nr -(LRRr?] | 
RO EER EG RE fe Seger ee ae ea alee Soe Sa 1 | 
axVs TH, Pb-Hui LLRRI? | ! 


a<NrsVs 
SS re ee ee 
a<Vs 


a<NrsVs 


cR+RJN 


bLt+a<Vs LINK_OPENED 


a<NrsVs \ LINK_OPENED 
RIN CHR ACR te eee ee a eee 
a<Vs 


a<NrsVs 
BSE + eee ee ee ah Ry Se ee 
a<Vs LINK OPENED 


a<NrsVs LINK OPENED 
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CHART 6-U: 


Stimuli 


P: V3 


LPR 
LXC 
LXR°}2  cHul|R+ 
xNul | 0 
x] 
x10 
cD 
cX 
cr 
age 
LTR°|2  cNul |R+ 
tNul !0 
tl 
tI0 
cD 
cx 
cT 
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ALT 


- 


U-format LPDUs in CHECKPOINTING State 


Action(s) | [PDU Transfers] New State 

IH, Vi=R, VF=P, ieee & by LINK RESETING 
IH, TT1, ITi (LUA']) LINK CLOSED 
IH (RE), TT1, ITi, Pr=L [LPR°]} LINK RECOVERY 
THs: Thy E91 LINK CLOSED 
IH, TT1, ITi, Ct=OQ, Pr=R ; LINK_RECOVERY 


IH, Vf=P, Px=R 


IH_(RE), TT1, ITi, Pr=L [LPR°]!} LINK RECOVERY 

IH, Px=Nul, RT1 [LRRc?] 

IH, Px=0, RT1 cae 

Pe=Nul, TTi, RT1, Ct=0 [LDC] LINK_CLOSING 
hl Mescsitis “seceete: ) Geum) — nia a tay, ae eae Gee os etary ee Reps antec nga cetera, | Sein Hee oat eaten teed 1 

Pe=Nul, Px=I, TTi, RT1, Ct=@ [LXC!(id)]| ! 


Pe=Nul, Pt=I, TTI, RT1, Ct=0 
[LTC (data) ] 


IH, Vf=P, Pt=0 


IH_ (RE), TT1, ITi, PreL [LPR°]} LINK RECOVERY 
IH, Pt=Nul, RT1 [LRRc?] 


TH, Pt=0, RT1 [LRRc!] 


LINK CLOSING 


Pc=Nul, Pt=I, TTI, RT1, Ct=0 


[LTC (data) ] 


M.8.2.7 LINK_RESETING State 


CHART 7-E: EVENTS in LINK_RESETING State | 


Vi=P, Va=Vr=Vs=0, ITi [LUA"]} LINK OPENING 
Vi=NUL, TT1, ITi [LDM®} LINK_CLOSED 
Ph=L 


ee 


eee 


| XLBSY = bNUL LE 


ELPDU IH_(RE), TT1l, ITi, Pr=L [LPR°]; LINK_RECOVERY 


=< 
ao 
=x 
— 
© 
| seed 
Mm 


CHART 7-I: I-Format LPDUs in LINK_RESETING State 


Stimuli P: V: .ALT| Action(s) ! [PDU Transfers] 
| pS 
CHART 7-S: S-format LPDUs in LINK_RESETING State 


Action(s) [PDU Transfers] 


Stimuli Ps: Vz ALT 


LRR|LNR|LRJ 
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CHART 7-U: U-format LPDUs in LINK_RESETING State 


Stimuli Ps: Vs ALT} Action(s) ; [POU Transfers] New State 


LSM TH, Vf=P 


Cae 


U 
P 


A 

IH, Vi=Nul, TT1l, ITi LINK_CLOSED 
IH, Vi=NUL, TT1, ITi, Ct=0, Pr=R LINK_RECOVERY 
ee 
Ce 
| LTR 
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M.8.2.8 LINK RECOVERY State 


CHART 8-E: EVENTS in LINK_RECOVERY State 


Stimuli P: V: ALT] Action(s) [PDU Transfers] 
Ce 


VieL, TTi, IT1, Ct=0 [LSM!]] LINK OPENING 


LINK CLOSING 


TTi, IT1, Ct=0 [LDC] 


bB Pb=R | 
ELSE ee | 
XCHID LE 
LTEST LE 7 ae 
ELPDU IP | | 


CHART 8-I: I-Format LPDUs in LINK_RECOVERY State 


CHART 8-S: S-format LPDUs in LINK_RECOVERY State 


Stimuli P: V: ALT} Action(s) [PDU Transfers] 
ST a 


Appendix M. Description of the Enhanced Logical Link Control - (ELLC) Procedures M-55 


CHARi 8-U: U-format LPDUs in LINK_RECOVERY State 


Stimuli P: Vs. ALT} Action(s) [PDU Transfers] 


LINK_RESETING 
LINK_CLOSED 
IH, Ti, 1 LINK_CLOSED 


TH, Pr=Nul, Vi=R, Vf=P, ITi 


IH, TT1, ITi [LUA'] 
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M.8.3 Basic Procedure Definitions 


M.8.3.1 Acknowledgment 


CHART A: Procedure for the ELLC Acknowledgment Processing 


Stimuli P: Vs ALT j [Frame Transfers] 


a<Nr<Vs 


M.8.3.2 Limit 
CHART L: Procedure for the ELLC Limit Processing 


Stimuli Ps V: ALT; Action(s) [Frame Transfers] New State 
\ 


Ct='Ct+l' then » 


Ct=LN2 TH, TT1, ITi 


ELSE 


M.8.3.3 Rejection 
CHART R: Procedure for the ELLC Rejection Processing 
Stimuli Ps: Vs ALT} Action(s) [Frame Transfers] New State 


a<Nr<Vs | Va=Nr, RT1 


M.8.3.4 Link Test 


CHART T: Procedure for the Link_Test Processing 


Stimuli P: V: ALT] Action(s) [Frame Transfers] 


+ c+xt+tNul | Pt=I, TTi, RT1, Ct=0 


c+xNul+t0 


c+xNul+tIo 


ELSE 
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M.8.3.5 Exchange identification 


CHART X: Procedure for the Exchange Identification Processing 


Stimuli P: V: ALT} Action(s) [Frame Transfers] 


c+t+xNul Px=I, TTi, RT1, Ct=0 [LXC?] 


c+tNul+x0 


c+tNul+xI0 


ELSE 
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Restricted use of certain capabilities, formats and/or procedures 
+ described in the 1984 “RED BOOK” version and the 1988 “BLUE BOOK” 
on version of CCITT Recommendation X.25 may be required for compatibility 
with specific implementations designed to comply with earlier versions of 
the Recommendation. IBM SNA X.25_ 1984/1988 DTEs required to operate 
with stations implemented in accordance with the 1980 “YELLOW BOOK” 
version of CCITT Recommendation X.25 as described in GA27-3345-2, may 
restrict the use of certain 1984/1988 capabilities as delineated in “PHYS- 
ICAL LAYER” through “CCITT-Specified DTE Facilities” on page N-9. 


++ 44 


N.1. PHYSICAL LAYER 


N.1.1 Differences between 1988 and 1984 X.25 


+N.1.1.1 Signaling Rates 

++ American National Standards ANS X3.100 and Federal Information Proc- 
+ essing Standard FIPS 100-1 require that all networks support data rates of 
+ 4800 and 9600 kKbits/s. They also specify 56 kbits/s as a standard rate in 
Bo North America and recommend it in place of the 48 kbits/s rate specified 
te in CCITT Recommendation X.1. Also, 64 kbits/s is recommended in 

+ anticipatin of the Integrated Services Digital Networks (ISDN). 

+ N.1.1.2 Access via ISDN B-Channel 

fe CCITT Recommendation X.25 (1988) allows access to the network via an 

+ Integrated-Services Digital Network (ISDN) B-Channel as specified in 

+ CCITT Recommendation X.31. This is an optional capability. 

+N.1.2 Differences between 1984 and 1980 X.25 

+ In addition to the differences listed above, the following items must be 

+ taken into consideration to operate with the 1980 version of X.25. 
+N.1.2.1 V-Series Interface 

+ specific X.25 1984/1988 interface details, related particularly to failure 

zs detection principles, loop testing and the use of specific circuits (Ref. 

h Section 1.3 of CCITT Recommendation X.25_ 1984/1988), are not included in 
+ CCITT Recommendation X.25_ 1980. 


e For 1980 operation, dependence on specific V-series procedures 
should be avoided except as “Network Specific” options. 
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N.2 DATA LINK LAYER 


+ N.2.1 Differences between 1988 and 1984 X.25 


+ N.2.1.1 DTE/DTE Operation 


+e F+HeeHeet 


++4++4 


+ 


+++ +4 


Although not specified in CCITT Recommendation X.25, International 
Standards Organization ISO 7776 supports communication between two 
DTEs without an intervening network. Since there is no intervening 
network, link layer characteristics must be made by bilateral agreement 
rather than at subscription time. This is an optional capability but is 
required if Open Systems-Interconnect (OSI) is supported. 


N.2.1.2 Clearing a FRMR Condition at the DCE 


After the DCE has transmitted a FRMR response, the frame rejection con- 
dition is cleared when the DCE receives a FRMR response (in addition to 
when a SABM/SABME, DISC, or DM is sent or received). 


N.2.1.3 Maximum Number of Outstanding Il-Frames 


American National Standards ANS X3.100 specifies that all networks must 
support K=7. K is the maximum number of outstanding I-frames. This is 
required to claim conformance to ANS X3.100 or FIPS 100-1. 


N.2.2 Differences between 1984 and 1980 X.25 


In addition to the differences listed above, the following items must be 
taken into consideration to operate with the 1980 version of X.25. 


N.2.2.1 Phase Synchronization 


Initiation of the link disconnection procedure ({i.e., transmission of a DISC 
command) by either X.25_ 1984/1988 station is specifically permitted, to 
insure ‘Phase Synchronization’ prior to initiation of the link set-up proce- 
dure (Ref. Section 2.4.4.1 of CCITT Recommendation X.25_ 1984/1988). 


« For 1980 operation, the ‘Phase Synchronization’ procedure may be 
used only as a “Network Specific” option. 


N.2.2.2 Initialization Phase 


X.25 1984/1968 stations, having transmitted an SABM/SABME command, 
ignore and discard any frames received except an SABM/SABME or DISC 
command, or a UA or DM response (Ref. Section 2.4.4.1 of CCITT Recom- 
mendation X.25 1984/1988). 


e For 1980 operation, specific implementations may treat received 
frames, containing other than SABM/SABME or DISC commands, 
or UA or DM responses differently since an ‘Initialization Phase’ 
was heretofore undefined. 


Also, in the event of SABM/SABME command collisions, 
X.25 1984/1988 stations enter the information transfer phase either: 


° after receiving the UA response, 

e after sending the UA response, or 

¢ after having sent a UA response and timing out waiting for the 
UA response 
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+ 


+ 
+ 


and accept a subsequent UA response received within the 
time-out interval as normal (Ref. Section 2.4.4.5.1 of CCITT Recom- 
mendation X.25_ 1984/1988. 


¢ For 1980 operation, receipt of a UA response while in the infor- 
mation transfer phase may be treated as an exception condi- 
tion resulting in initiation of either the link resetting or 
disconnection procedure. 


N.2.2.3 Disconnection Phase 
X.25_ 1984/1988 stations, having transmitted a DISC command, ignore and 
discard any frames received except an SABM/SABME or DISC command, 
or a UA or DM response (Ref. Section 2.4.4.3 of CCITT Recommendation 
X.25 1984/1988). 


e For 1980 operation, specific implementations may treat received 
frames, containing other than SABM/SABME or DISC commands, 
or UA or DM responses differently since a ‘Disconnection Phase’ 
was heretofore undefined. 


Also, in the event of DISC command collisions, X.25 1984/1988 stations 
enter the disconnected phase either: 


1. after receiving the UA response, 

2. after sending the UA response, or 

3. after having sent a UA response and timing out waiting for the 
UA response 


and accepi a subsequent UA response received within the time-out 
interval as normal (Ref. Section 2.4.4.5.1 of CCITT Recommendation 
X.25_ 1984/1988. : 


e for. 1980 operation, stations enter the disconnected phase only 
after receipt of a UA response or after sending a UA response 
and timing out waiting for a UA response. 


N.2.2.4 Rejection Recovery 
Duplicate re-transmission of the I-frames within the same numbering 
cycle, by X.25 1984/1988 stations, is specifically prohibited (Ref. Section 
2.4.5.9 of CCITT Recommendation X.25 1984/1988). 


¢ For 1980 operation, duplicate I-frame re-transmissions within the 
same numbering cycle are ignored. 


N.2.2.5 Extended Frame Sequencing Mode 
An optional extended mode of station operation, wherein frame 
sequencing may be performed modulo 128, is defined for X.25 1984/1988 
Stations (Ref. Section 2.4 of CCITT Recommendation X.25_ 1984/1988). 


e For 1980 operation, stations are restricted to the Basic Mode of 
operation wherein frame sequencing is performed modulo 8. 
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N.2.2.6 Multi-link Procedures (MLP) (Subscription-time Selectable Option) 

+ | X.25 1984/1988 stations may use an optional MLP to distribute outgoing 

a packets across the SLPs available at the origin DTE/DCE interface and re- 
sequence incoming packets received from the SLPs at the destination 
DTE/DCE interface for delivery to the packet layer (Ref. Sections 2.1 and 

+ | 2.9 of CCITT Recommendation X.25_ 1984/1988). 


¢ For 1980 operation, the multi-link procedures cannot be used. 


N.2.2.7 Flag Sequences 
a ; sequences of contiguous flags transmitted by X.25 1984/1988 stations are 
+ * restricted to complete 8-bit flag sequences (e.g., ‘011111100111...1110’) 
a (Ref. Section 2.2.2 of CCITT Recommendation X.25_ 1984/1988). 


° For 1980 operation, stations may be required to recognize shared 
‘0’ bit flag sequences (e.g., 011111101111110...01111110°) as well 
as multiple complete 8-bit flag sequences (e.g., 
‘011111100111...1110') as sequences of contiguous flags. 


N.3 PACKET LAYER 


+N.3.1 Differences between 1988 and 1984 X.25 


+ N.3.1.1 Network User Identification (NUI) 
2% Network_User_ Identification (NUI) related facilities has been divided into 
three optional facilities: 


+ 
+ NUI subscription 
+ NUL override: 

4 


NUI selection 


+ N.3.1.2 DTE/DTE Operation 

+ DTE to DTE operation without an intervening network has been defined. In 
+ this situation, one DTE must act as DCE. The DTE acting as DCE at packet 
+ layer may be acting as DTE at Data Link Layer and vice versa. This is an 
+ optional facility but is required to support Open Systems Interconnect 

+ (OSI). 


N.3.1.3 Circuit-switched Connection without Prior Agreement 
A circuit-switched connection without prior agreement (Such as electronic 
mail-order) has been defined and default values specified for all appli- 
cable parameters. This is an optional capability. 


+++ + 


+ N.3.1.4 Throughput Class of 64000 bits/s 
+ A new throughput class of 64000 bits per second has been defined. This 
+ is an optional capability. 
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+ N.3.1.5 Address Block Definition 


+ 
+ 
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A new Address Block has been defined for call setup and clearing packets 
which allows addresses of 12 or 15 digits. This is an optional capability. 


N.3.1.6 TOA/NPI Address Subscription 


A new facility, TOA/NPI_ Address Subscription, has been added to accom- 
modate E.164 (ISDN) addresses of up to 17 digits in length. This addition 
results in a redefinition of the “address block” and the consequent defi- 
nition of new formats for the CALL REQUEST, CALL ACCEPTED, 

CALL CONNECTED, CLEAR_REQUEST, CLEAR_INDICATION, and 

CLEAR CONFIRMATION packets. This is an optional capability. 


N.3.1.7 Call_Deflection 


Call Deflection Selection facilities whereby the DTE forwards calls after 
receiving an INCOMING CALL packet (unlike Call_ Redirection which is 
handled in the network and the originally called DTE never receives an 
INCOMING CALL packet) has been added. There are three call deflection 
facilities: 


Call_ Deflection Subscription which enables the DTE to request 
Call_Deflection_Selection. 


Call Deflection Selection which may be used on a per virtual call 
basis only if Call Deflection Subscription has been subscribed to. 


Call Deflection Notification which informs the alle lMale DTE that the 
call has been forwarded. 


These are optional user facilities. 


N.3.1.8 Priority Facility 


A Priority Facility has been added to specify the priority of data on a con- 
nection, priority to gain a connection, and priority to keep a connection. 
This is an optional capability. 


N.3.1.9 Protection Facility 


A Protection Facility has been added to allow specification of a protection 
code. This is an optional capability. 


N.3.1.10 Maximum size of Called and Calling Address Extension 


The maximum size of the called and calling address extension fields are 
extended from 32 to 40 digits and an OSI/non-OSI indicator has been 
added. Support of the larger address Is optional. However, a test of the 
OSI/non-OSI indicator is required to determine the size of the called and 
calling addresses. 


N.3.1.11 Recognized_Private_Operating Agency (RPOA) 


RPOA related facilities have been divided into two facilities: 
RPOA_ Subscription which applies to all virtual calls 


RPOA_ Selection which applies to a given virtual call and does not 
require RPQA_ Subscription. 


These are optional capabilities. 
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+ N.3.1.12 Mandatory Address Length Fields in CALL_ ACCEPTED packets 
The use of the Address Length Fields in CALL_ACCEPTED packets is man- 
+ datory, even if they are set to zero. 


N.3.1.13 Mandatory Facility Length Fields in CALL_ACCEPTED packets 
The use of the Facility Length Fields in CALL_ACCEPTED packets is man- 
datory, even if they are set to zero. 


++ + 


N.3.1.14 Virtual Circuit Clearing/Resetting Failure | 
e When a CLEAR_REQUEST packet is not confirmed within time-limit 
T23, the DTE will retry the call clearing procedure up to R23 times, at 
T23 intervals, before notifying the higher layer (virtual circuit user) of 
the failure; leaving the logical channel in the DTE_CLEAR_ REQUEST 
state {p6) rather than “placing the logical channel in an inoperative 
state” as specified by earlier versions of this document. 


e When a RESET REQUEST packet is not confirmed within time-limit 
T22, the DTE will retry the resetting procedure up to R22 times, at T22 
intervals, defore notifying the higher layer (virtual circuit user) of the 
failure; leaving the logical channel in the DTE_RESET REQUEST state 
(d2), rather than “placing the logical channel in an inoperative state” 
as specified by earlier versions of this document. 
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These changes are mandatory. 


+N.3.2 Differences between 1984 and 1980 X.25 
+ In addition to the differences listed above, the following items must be 
+ taken into consideration to operate with the 1980 version of X.25. 


N.3.2.1 Expanded User Data Fields 
DATA packets transmitted by X.25 1984/1988 stations may include up to 
2048 and 4096 octets of User Data (Ref. Sections 4.3.2, 6.9, 6.12 and 
7.2.2.1.1 of CCITT Recommendation X.25 1984 or 1988); 


+++ 


e For 1980 operation, DATA packets are limited to a maximum of 
1024 octets of User Data. 


N.3.2.2 Expanded Facility Fields 
Facilities transmitted in CALL REQUEST, INCOMING CALL, 
CALL ACCEPTED, and CALL_CONNECTED packets by X.25_ 1984/1988 
stations may include up to 109 octets (Ref. Sections 5.2.1, 5.2.2, 5.2.3 and 
5.2.4 and Figures 2/X.25, 3/X.25, 4/X.25 and 5/X.25 of CCITT Recommenda- 
tion X.25_ 1984/1988); 


e For 1980 operation, facilities are limited to 63 octets and bit 7 as 
well as bit 8 of the Facility Length must be set equal to ‘0; 


+++ + 


N.3.2.3 Expanded DTE Cause Codes 
+ ‘DTE-Originated’ cause codes transmitted by X.25 1984/1988 stations, in 
CLEAR_REQUEST, CLEAR_INDICATION, RESET REQUEST, 
RESET INDICATION, RESTART REQUEST and RESTART_INDICATION 
packets, may have the value x‘00’; or, x‘80’ (Ref. Sections 5.2.3, 5.4.3 and 
+ 5.5.1 and Tables 18/X.25, 19/X.25 and 20/X.25 of CCITT Recommendation 
+ X.25 1984/1988); 
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¢ For 1980 operation, the ‘DTE-Originated’ cause code is restricted 
to the value x00’. 


N.3.2.4 Restricted Address and Facility Lengths 
CLEAR_REQUEST and CLEAR_INDICATION packets transmitted by 
X.25_ 1984/1988 stations may include non-zero Address and Facility Length 
Fields (Ref. Section 5.2.3.2 and Figure 4/X.25 of CCITT Recommendation 
X.25_ 1984/1988): 
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« For 1980 operation, these length fields are permitted only when 
the packet contains Clear User Data and must indicate zero 
octets; 


N.3.2.5 Extended DCE CLEAR_CONFIRMATION packets 
An extended format for DCE CLEAR CONFIRMATION packets is defined 
for use by X.25_ 1984/1988 DCEs in conjunction with the 
Charging _ Information facility described in section 6.22 of CCITT Recom- 
mendation X.25 1984/1988 (Ref. Section 5.2.4 and Figure 5/X.25 of CCITT 
Recommendation X.25 1984/1988): 


¢« For 1980 operation, DCE CLEAR CONFIRMATION packets are 
restricted to basic format which does not include facilities. 


++ +4 


N.3.2.6 Extended Interrupt User Data Fields 


+ INTERRUPT packets transmitted by X.25_ 1984/1988 stations may include 
+ up to 32 octets of User Data (Ref. Section 5.3.2 and Figure 7/X.25 of CCITT 
+ Recommendation X.25 1984/1988): 


e For 1980 operation, INTERRUPT packets include exactly one octet 
of User Data. 


N.3.2.7 Time-Out Retry Procedures 
fe When packet layer operations are to be retried {as specified in Table D-2), 
+ they are retried by X.25 stations ‘n > 1’ times following expiration of 
i system specified time-outs (REF. Annex D to CCITT Recommendation 
X.25_ 1984/1988; 


e For 1980 operation, packet layer operations may be retried ‘n > 0’ 
times following expiration of system specified time-outs. 


N.3.3 Additional Optional User Facilities 
+ New optional user facilities that may be used by X.25 1984/1988 stations 
include: 


¢ On-line Facility Registration (Ref. Section 6.1 of CCITT Recommen- 
dation X.25 1984/1988), 

e Local Charging Prevention (Ref. Section 6.20 of CCITT Recommen- 
dation X.25 1984/1988), 

e Network User identification (Ref. Section 6.21 of CCITT Recommen- 
dation X.25 1984/1988), 

e Charging Information (Ref. Section 6.22 of CCITT Recommendation 
X.25 1984), 

e Hunt Group (Ref. Section 6.24 of CCITT Recommendation 
X.29_ 1984/1988), 

e Call Redirection (Ref. Section 6.25 of CCITT Recommendation 
X.29 1984/1988), . 


++++ +4 
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* Called Line Address Modified Notification (Ref. Section 6.26 of 


CCITT Recommendation X.25 1984/1988), 


¢« Call Redirection Notification (Ref. een 6. 27 of oun Recom- 


mendation X.25 1984/1988), and. 


.¢. Transit Delay Selection and. ingicsion (Ref. Section 6. 08 of CCITT 


Recommendation X.25_ 1984/1988), 


— For 1980 operation, none of the Sone User Facilities listed 
above can be used; 3 


N.3.4 Expanded Capabilities. 


Expanded capabilities for some eorouae user r facilities that may be used 
by X.25_ 1984/1988 stations include: 
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1. Closed User Groups (CUG): X.25 (1984/1988) DTEs may be able to 


subscribe to: 


a. the Closed User Group with Outgoing Access and/or 
Incoming Access Facilities without designating a 
peferential CUG (Ref. Sections 6.14.2 and 6.14.3, respec- 
tively, of CCITT Recommendation X.25_ 1984/1988; 

b. the use of the extended format of the CUG Selection 
Facility for indicating membership in more than 100 
CUGs (Ref. Section 6.14.6 of CCITT Recommendation 
X.25_ 1984/1988); and 

c. the use of the Closed User Group with Outgoing Access 
(CUG/OA) Selection Facility (Ref. Section 6.14.7 of CCITT 
Recommendation X.25 1984/1988). 


¢ For 1980 operation, all CUG subscriptions 
require a preferential CUG; only the basic 
format of the CUG Selection Facility, which 
restricts membership in 100 or less CUGs, is 
allowed; and, the CUG/OA Selection Facility 
cannot be used, 


2. Fast Select and Fast Select Acceptance (Ref. Sections 6.16 and 


6.17, respectively, of CCITT Recommendation X.25 1984): / 
CLEAR REQUEST and CLEAR_INDICATION packets transmitted by 
X.25 (1984/1988) stations after call setup has been completed may 
incluce Clear User Data (Ref. Section 5.2.3.2 and Figure 4/X.25 of 
CCITT Recommendation X.25_ 1984/1988); 


¢ For 1980 operation, Clear User Data may be included in 
CLEAR_REQUEST and CLEAR_INDICATION packets only 
when sent or received in direct response to an 

INCOMING CALL or a CALL REQUEST packets, respec- 
tively, and 


. RPOA Selection (Ref. Section 6.23 of CCITT Recommendation 


X.25_ 1984/1988): X.25 1984/1988 DTEs may be able to use an 
extended format of the RPOA Selection Facility to select one or 
more RPOAs, and agreement for a period of time with the DCE to 
a set of RPOAs to pertain to all CALL REQUEST packets; 


e For 1980 operation, RPOA Selection is limited to : 
CALL REQUEST packets and can only use the basic format 
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of the RPOA Selection Facility to select a single RPOA; 
and 


N.3.5 CCITT-Specified DTE Facilities 
The CCITT-specified DTE facilities, described in Appendix: G, 
“CCITT-Specified DTE Facilities,” that X.25 1984/1988 may be able to use, 
include: 


1. Calling DTE Address Extension (Ref. Annex G.3.1 of CCITT Recom- 
mendation X.25_ 1984/1988), 


2. Called DTE Address Extension (Ref. Annex G.3.2 of CCITT Recom- 
mendation X.25_ 1984/1988), 


3. Quality of Service Negotiation (Ref. Annex G.3.3 of CCITT Recom- 
mendation X.25 1984/1988), 


4. Expedited Data Negotiation (Ref. Annex G.3.4 of CCITT Recommen- 
dation X.25 1984/1988): 


¢ For 1980 operation, use of any of these ‘CCiTT-Specified DTE 
Facilities’ and the associated Facility Marker (see “General” 
on page 7-1), x‘OF’, is prohibited. 
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Appendix O. Description of the BNN Qualified Logical — 
Link Control - (QLLC) Procedures 


QLLC provides adjacent SNA node physical services where such nodes 
are connected through ‘X.25-based’ PSDN services. It uses HDLC unnum- 
bered and supervisory Receive Ready commands and responses, iden- 
tical to their SDLC counterparts, carried as User Data in Q-packets. QLLC 
commands and responses are initiated by the same higher layer events 
that initiate their SDLC counterparts; timeout processing, as in SDLC, may 
be required for all QLLC commands. 


QLLC procedures are defined for balanced (peer-to-peer), primary, and 
secondary link station configurations. 


In peer-to-peer QLLC, either link station may initiate actions (i.e., transmit 
commands}; HDLC asynchronous balanced mode (ABM) functions are uti- 
lized for peer-to-peer QLLC. 


In primary/secondary QLLC, only primary link stations initiate actions. 
HDLC normal response mode (NRM) functions are utilized for 
primary/secondary QLLC where primary link stations transfer commands 
to which secondary link stations respond. Secondary stations may also 
transfer the QRD response asynchronously to solicit initiation of the dis- 
connection procedure by the primary link station. 


Procedures for use of the QLLC protocols by balanced, primary, and sec- 
ondary link stations are described in this section. In addition, some 
stations may function as ‘combined’, or ‘configurable’ stations that exhibit 
balanced characteristics until role negotiation is completed via exchanges 
of identification information. After such role negotiation is completed, 
‘combined’ or ‘configurable’ QLLC link stations assume the role and func- 
tions of either primary or secondary depending on the outcome of the role 
negotiation process. 
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Introduction 


QLLC is the ‘base architecture’ for logical link control to be provided by all 
IBM SNA X.25 DTEs, except the 5973 NIA and the 5251-M12. It uses X.25 
DATA packets with the ‘Qualifier Bit’ equal to one (Q = 1), also referred 
to as ‘Q-packets’, to transfer HDLC-like commands and responses. 


QLLC is used by two adjacent link stations to exchange elementary units 
of information over link connections in one of several environments: peer- 
to-peer, primary/secondary, or indirectly coupled; the environments are 
illustrated in Figure O-1 on page Q-3. One link station acts as either a 
peer or primary link station, associated with a DTE attached to a PSDN via 
an X.25 DTE/DCE interface, and communicates with another link station, 
associated with a partner DTE attached to the same or some other inter- 
connected PSDN, which acts as either a peer or secondary link station, 
respectively. | 
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In indirectly coupled configurations, a packet assembly/disassembly (PAD) 
function, provided either by the PSDN or as a stand-alone interface 
adapter, acts as the ‘REMOTE DTE’ and correlates actions that take place 
across the link connection to actions that take place across the access 
link connecting the interface adapter and the secondary link station. In 
this environment the secondary link station is referred to as the ‘Related 
secondary Station’ (RSS). 


The objective of QLLC is to provide adjacent node physical services equiv- 
alent to those used by SDLC in SNA. It helps to keep the ‘LOCAL DTE’ 
informed of the situation in the ‘REMOTE DTE’ and/or the ‘Related Sec- 
ondary Station’. Segmentation and concatenation of DATA packets may 
be performed by the packet layer procedures at both ends of the link con- 
nection by means of the More Data Mark ‘M-bit’ procedures defined in 
“More Data Mark” on page 4-9. 


The basic elements of information exchanged are called Logical Link Units 
(LLUs). Two types of LLUs are defined: 


QLLUs - composed of commands or responses which together with 
their uses and the resultant actions performed by link stations at both 
the local and remote DTEs are described in “QLLC Commands and 
Responses” on page O-9. QLLUs are conveyed between adjacent link 
stations in Q-packets formatted as shown in Figure O-2 on page O-8. 


DLLUs - appearing as SNA Basic Transmission Units (BTUs), and 
carried in the User Data field of X.25 DATA packets with the ‘Q = 0’ 
and the ‘M = Oor 1’, are used to convey user data between adjacent 
link stations in local and remote DTEs as described in “DTE and 

DCE DATA Packets” on page 5-20. 


X.25 Delivery Confirmation ‘D-bit’ procedures are not used. 
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Figure O-1. Qualified Logical Link Control Station Configurations 


O.2 Elements of Procedure 


The elements of procedure for QLLC include states, predicate conditions, 
external stimuli, Q-packet formats, commands, responses, and function 
descriptions. : 


Link connections are perceived by link stations as being in one of six 
states (see “States” on page O-4) at any particular instant in time. 


Predicate conditions are protocol variables (see “Predicate Condition” on 
page O-5) that influence the specific procedures performed in the various 
states. 


External stimuli are station events (see “External Stimuli” on page O-6) 
that are inputs to the QLLC finite state machines. The Receive Data and 
send Data events are data received or data to be transmitted, respec- 
tively, while Erroneous QLLU signifies a received Q packet that contains 
an unrecognizable command or response. All other stimuli are local 
events. 
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0.2.1 States 
0.2.1.1 CLOSED 


0.2.1.2 CLOSING 


Q-packet formats (see “Q-Packet Formats” on page O-7) define qualified 
data packets which carry QLLC commands and responses between link 
Stations in adjacent nodes. 


Function descriptions (see “Function descriptions” on page O-13) are 
expanded definitions of some of the functions specified by the QLLC finite 
state machine; other functions are self explanatory. 


The CLOSED state is the initial operational state. Link stations having 
transmitted or received a QDISC command QLLU and received or trans- 
mitted a QUA response QLLU, respectively, perceive the link connection 
to be in the CLOSED state. Peer and primary link stations complete 
exchange of identification information (QXID), or link test (QTEST) proce- 
dures, on behalf of the higher layer, across link connections perceived to 
be in this state. Some may also initiate a link set-up procedure (transmit 
a QSM command). Secondary link stations accept and respond to QXID 
and QTEST commands received across link connections perceived to be 
in this state. Some may also accept and respond to QSM commands. 


Link stations having initiated a link disconnection procedure (transmitted a 
QDISC command or QRD response) perceive the link connection to be in 
the CLOSING state until the link disconnection procedure is successfully 
completed or terminated unsuccessfully. Peer, primary and secondary 
link stations await successful completion or unsuccessful termination of 
link connections in this state. 


0.2.1.3 INOPERATIVE (INOP) | 


0.2.1.4 OPENED 


0.2.1.5 OPENING 


The INOPERATIVE state is the initial state. Link connections are per- 
ceived by link stations to be in an INOPERATIVE state when the supporting 
virtual circuit is inoperative. Peer, primary and secondary link stations on 
link connections perceived to be in this state neither transmit nor receive 
QLLUs or DLLUs and require a higher layer stimulus to become opera- 
tional. 


Link stations having transmitted or received a QSM command QLLU and 
having received or transmitted, respectively, a QUA response QLLU per- 
ceive the link station to be in the OPENED state. QLLUs and DLLUs may 
be transmitted and received both by the called and link stations across 
link connections perceived to be in this state. 


Link stations participating in the link set-up procedure perceive the link 
connection to be in the OPENING state until that procedure is successfully 
completed or terminated unsuccessfully. Peer and primary link stations, 
having transmitted a set mode {QSM) command across the link con- 
nection expect to receive a response (QUA or QDM) within a user speci- 
fied time-limit. Peer link stations also respond (QUA) to set mode (QSM) 
commands received across link connections perceived to be in this state 
at the first opportunity. Secondary link stations accept and respond (QUA) 
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to set mode {(QSM) commands received across link connections perceived 
to be in this state at the first opportunity. 


0.2.1.6 RECOVERY 
The RECOVERY state is comparable to the data link layer frame rejection 
phase. Peer and secondary link stations retransmit the QFRMR response 
on link connections perceived to be in this state at each respond opportu- 
nity until recovery is effected by the adjacent link station, or until internal 
recovery is initiated locally. A primary link station does not have a 
RECOVERY state. | 


0.2.2 Predicate Condition 


The values that may be assigned to the predicate condition are: 


0.2.2.1 Contact Termination Pending (CTp) 
Represents the secondary link station condition in which receipt of a DLLU 
or a Receive Ready (QRR) command QLLU from the primary link station is 
required tc terminate the SNA_CONTACT phase on link connections per- 
ceived to be in the OPENING state. 


0.2.2.2 Incoming/Outgoing TEST Response Pending (JOTRp) 
Transmission and receipt of TEST response QLLUs containing test pat- 
terns to and from the link station in the adjacent node are pending. 


0.2.2.3 Incoming/Outgoing XID Response Pending (IOXRp) 
Transmission and receipt of XID response QLLUs containing link station 
identification information to and from the link station in both adjacent 
nodes are pending. 


0.2.2.4 Incoming TEST Response Pending (ITRp) 
Receipt of a TEST response QLLU containing the test pattern from the link 
Station in the adjacent node is pending. 


0.2.2.5 TEST/XID Response Pending (ITOXRp) 
Receipt of a TEST response QLLU containing the test pattern from and an 
XID response QLLU containing link station identification information to the 
link station in the adjacent node are both pending. 


0.2.2.6 XID/TEST Response Pending (IXOTRp) 
Receipt of an XID response QLLU containing link station identification 
information from and transmission of a TEST response QLLU containing 
the test pattern to the link station in the adjacent node are both pending. 


0.2.2./ Incoming XID Response Pending (IXRp) 
Receipt of an XID response QLLU containing link station identification 
information from the link station in the adjacent node is pending. 


0.2.2.8 No Predicate Condition (NULL) 


Signifies that no transient predicate condition exists to alter the action 
required of the link station. 
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0.2.2.9 Outg 


oing TEST Response Pending (OTRp) 


Teanetmiesion of a TEST response QLLU containing the test pattern to the 
link station in the adjacent node is pending. 


0.2.2.10 Outgoing XID Response Pending (OXRp) 


Transmission of an XID response QLLU containing link station identifica- 
tion information to the link station in the adjacent node is pending. 


0.2.2.11 Remote RESTART Pending (RRp) 


A restart of the packet layer interface providing remote DTE access to the 
network is pending. 


0.2.2.12 SET_MODE Pending (SMp) 


some QLLC link stations (see note 1 in the QLLC FSM) are sacri’ to 
complete link initialization only after a successful exchange of identifica- 
tion information; these stations use the predicate condition value of SMp. 


0.2.3 External Stimuli 


0.2.3.1 Erroneous QLLU 


0.2.3.3 


0.2.3.4 


0.2.3.5 


0.2.3.6 


0.2.3.7 


0.2.3.8 


Exchange __ 


Link _Start 


Link Stop 


Link Test 


Represents receipt of an erroneous qualified logical link unit (QLLU) (e.g., 
a Q PACKET containing an unidentifiable or not supported command or 
response or information field too long) on the link connection. 


identification | | 
Represents a higher layer request for or authorization to transfer logical 
link identification information. 


Represents a higher layer stimulus to initiate the logical link control 
set-up procedure for the link connection. 


Represents a higher layer stimulus to initiate the logical link control dis- 
connection procedure for the link connection. 


Represents a higher layer request for or authorization to transfer link test 
data. 


Link Timeout Expiration 


Represents expiration of link reply timeout, Timer Tq. 


Packet_Layer_Inoperative 


Represents a signal from the packet layer that the underlying virtual 
circuit is inoperative. | 


Packet_Layer_Ready 


Represents a signal from the packet layer that the underlying virtual 


circuit is in the READY state. 
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0.2.3.9 Receive Data 
| Represents the receipt of a data logical link unit (ODLLU) from the adjacent 
logical link station. 


0.2.3.10 Send_Data 
Represents a higher layer request for the transfer of a data logical link 
unit (DLLU) to the adjacent logical link station. 


0.2.3.11 Virtual_Circuit_Clear_Reset 
Represents a packet layer clearing of the virtual call, or resetting of the 
permanent virtual circuit, supporting the link connection. 


+ 0.2.3.12 Effects of LAPB Link Resetting 

Resetting of the data link layer re-initializes LAPB sequence numbering 
and constitutes an exposure to the integrity of data for either direction of 
transmission. Such exposures cannot be resolved by logical link stations 
using QLLC which is required to: | 


e report, an outage for each virtual circuit supported by the LAPB link, 
to a higher layer of SNA; and, 

* remove affected vitrual circuits from service by clearing virtual calls 
and resetting permanent virtual circuits. 
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0.2.4 Q-Packet Formats 
‘Q-packets’ used by QLLC conform to one of the formats depicted in 
Figure O-2 on page O-8. 
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General format identifier (GF1I) 
| 1 0 0 1 


Logical channel number 


ee ce 


QLLC Address Field 
(Coded x'FF' for Commands or # x'FF' for Responses 


QLLC Control Field | : 


: QXID/QTEST/QFRMR Information Field (Optional) 


(Modulo 8) 


General format identifier (GFI)| 
1 0 i 0 


| QLLC Address Field 
(Coded x'FF' for Commands or # x'FF' for Responses) 


QLLC Control Field 


n QXID/QTEST/QFRMR Information Field (Optional) 


(Modulo 128) 


M = More Data Mark 


Figure O©O-2. QUALIFIED DATA Packet Formats 


0.2.4.1 QLLC Address Field 
The address field consists of one octet. The contents of the address field 
is set to x‘FF’ in ‘Q-packets’ containing commands and to any value other 
than x‘FF’ in ‘Q-packets’ containing responses. 
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0.2.4.2 QLLC Control Field 


The control field consists of one octet. The control field contains the 
command/response transmitted by the peer, primary or secondary link 
Station as depicted in Figure O-3. 


0.2.4.3 QLLC Information Field 


The information field consists of a variable number of octets and is used 
to carry QXID, QTEST or QFRMR data. 


0.2.5 QLLC Commands and Responses 


Figure O-3 shows the code points for the HDLC commands/responses 
carried in Q-packets used by peer, primary and secondary QLLC link 
stations. 


Peer-to-Peer 


Command 


I-Field 
Allowed 


Secondary 
Response 


Primary 
Command 


QLLC 
Function 


QFRMR 


| Note: The Address field as defined for SDLC is octet 'O'. 


Figure ©-3. DTE and DCE DATA Packet User_Data Field Format 


0.2.5.1 Q_ Disconnect (QDISC) | 
The Disconnect command QLLU is transferred by peer and primary QLLC 
link stations to place the link connection, as perceived by the peer or sec- 
ondary QLLC link station in the adjacent node, in the CLOSED state. No 
information field is permitted with the QDISC command. 


Upon receipt of the DISC command QLLU peer and secondary QLLC link 


stations, on link connections perceived to be in other than the CLOSED 
state, transfer a UA response QLLU confirming acceptance of the QDISC 
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command and place the link connection in the CLOSED state. Link con- 
nections perceived to be in the CLOSING state, by peer and primary QLLC 
link stations, are placed in the CLOSED state upon receipt of a UA 
response QLLU by that QLLC link station. | 


0.2.5.2 Q Disconnected_Mode (QDM) 
The Disconnected Mode response QLLU may be transferred by peer and 
secondary QLLC link stations in response to QSM or QDISC commands. 
No information field is permitted with the QDM response. 


Receipt of a QDM response informs the receiving peer or primary QLLC 
link station that the link connection, as perceived by the communicating 
QLLC link station in the adjacent node, is in the CLOSED state. 


0.2.5.3 Q Frame_Reject (QFRMR) 
The Frame_Reject response QLLU may be used by peer and reeconian 
QLLC link stations to inform the communicating QLLC link station in the 
adjacent node of an error condition that cannot be recovered at the LLC 
layer, by retransmission of the identical LLU. 


Upon receipt of a QFRMR response, peer and primary QLLC link stations 
cause a clearing of the VC or a resetting of the PVC Supporting the link 
connection and inform a higher layer SNA protocol of the failure. The 
format of the information field of the Frame Reject response QLLU is 
depicted in Figure O-4 on page O-11. 
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“Treld:DITs 


1 
9 0 


Rejected LLU 


Control Field 


e Rejected LLU control field is the control field of the received 
LLU that caused the frame reject. 


e Vs is reserved and set to b 000’. 
¢ Vris reserved and set equal to b‘000°. 


e ‘W= 1’ indicates that the control field received and returned in bits 
1 through 8 was considered invalid or not implemented. 


e ‘X= 1’ indicates that the control field received and returned in bits 
1 through 8 was considered invalid because the LLU contained an 
information field which is not permitted or is an S or U-frame with 
incorrect length. ‘W=1' in required in conjunction with this bit. 


e ‘Y=1’ indicates that the information field received eyvyceeded the 
maximum established capacity of the link station reporting the rejection 
condition. 


e ‘Z’ is reserved and set equal to b‘0’. 


Note: Bit 13 is set to: 


‘1’ if the LLU rejected was a response; or, 
‘0’ if the LLU rejected was a command. 


Figure O-4. QFRMR Information Field Format 


0.2.5.4 Q Receive_Ready (QRR) 
The Receive Ready command QLLU may be transferred by peer and 
primary QLLC link stations to indicate that the link connection is in the 
OPENED state and the QLLC link stations are prepared to accept and 
respond to DLLUs. 


0.2.5.5 Q Request_Disconnect (QRD) 
The Request Disconnect response QLLU may be used by secondary QLLC 
link stations to request the primary QLLC link station to place the link con- 
nection as perceived by the secondary QLLC link station in the CLOSED 
State {i.e., initiate the link disconnection procedure by transferring a 
QDISC command across the link connection). As a result of receiving a 
DISCONTACT or similar request from a higher SNA layer, secondary 
QLLC link stations may transfer a QRD response, when no other 
responses (such as acknowledgments for received DLLUs or responses to 
received Unnumbered commands) are pending. The QRD response may 
be retransmitted a user specified number of times. DLLUs received by 
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the secondary QLLC link station after transmission of the QRD response 
and prior to receipt of the requested QDISC command are accepted and 
responded to in the normal way. No information field is permitted with the 
QRD response. 


Upon receipt of a QRD response the primary QLLC link station will 
transfer a QDISC command when authorized by a higher layers of SNA. 


0.2.5.6 Q Set_Mode (QSM) 
The Set_Mode command QLLU is transmitted by peer and primary link 
Stations to place the link connection, as perceived by the link station in 
the adjacent node,.in the OPENED state. No information field is permitted 
with the QSM command. 


Upon receipt of the Set_Mode command QLLU peer and secondary QLLC 
link stations, authorized by the higher layers of SNA, transfer a UA 
response QLLU confirming acceptance of the QSM command and place 
the link connection in the OPENED state. Peer and primary QLLC link 
stations, having transferred a Set_Mode command QLLU place the link 
connection in the OPENED state upon receipt of the UA response QLLU 
from the peer or secondary QLLC link station in the adjacent node. 


0.2.5.7 Q Test_Command and Q_ Test_Response (QTEST) 
The TEST command QLLU may be issued by peer and primary QLLC link 
stations at any time to solicit a TEST response QLLU from the peer or sec- 
ondary QLLC link station in the adjacent node. The information field of 
the TEST command/response contains the test pattern data. 


Upon receipt of a TEST command QLLU, peer and secondary QLLC link 
stations transfer the corresponding TEST response QLLU with the informa- 
tion field containing the test pattern data received in the QTEST command. 


0.2.5.8 Q Unnumbered_ Acknowledgment (QUA) | 
The Unnumbered Acknowledgment response QLLU is transferred by peer 
and secondary QLLC link stations in response to QSM or QDISC com- 
mands. No information field is permitted with the QUA response. 


Upon receipt of the QUA response across a link connection perceived by a 
peer or primary QLLC link station to be in the OPENING state, the 
receiving peer or primary QLLC link station places that link connection in 
the OPENED state. Upon receipt of the QUA response across a link con- 
nection perceived by a peer or primary QLLC link station to be in the 
CLOSING state, the receiving peer or primary QLLC link station places 
that link connection in the CLOSED state. 


0.2.5.9 Q XID Command and Q_ XID Response (QXID) 
| The Exchange _ Identification command QLLU may be issued by peer and 
primary QLLC link stations to solicit identification information from the 
peer or secondary communicating link station in the adjacent node. The 
information field of the QXID command/response contains the transmitting 
link station’s identification information. 


Upon receipt of an XID command QLLU, peer and secondary QLLC link 


stations transfer the corresponding XID response QLLU as soon as the 
identification information is available. 
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0.2.6 Function descriptions 


0.2.6.1 


0.2.6.2 


0.2.6.3 


0.2.6.4 


0.2.6.5 


0.2.6.6 


The following are descriptions of some of the functions specified by the 
QLLC finite state machine; see “Description of the Procedure” on 
page O-14. Other functions are self-explanatory. 


Increment Counter | 
‘Increment the retransmission count. If the transmission limit has been 
exceeded, notify a higher layer and wait for further directions. 


Inform Higher Layer 
Notify the higher layer of a particular occurrence and request help from 
the higher layer in formulating an appropriate answer. 


Ignore Logical Link Unit | 
Discard the data logical link unit (DLLU) or the qualified logical link unit 
{QLLU) just received from the packet layer. | 


Local Error 
Either ignore or report to a higher layer the Internal signalling error or 


illogical protocol sequence on the part of an entity at the local link station. 


Remote Error | 
Either ignore or report to a higher layer the protocol procedure error on 
the part of the QLLC link station in the adjacent node. 


Report Status 
Notify the higher layer that the QLLC link station has received a request 
from the remote station and may have responded to the information. 
Report status may also be used to notify the higher layer that the local 
link station has changed states. 
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+ 


0.3 Description of the Procedure 


A finite state machine is a graphical device that can be used to show how 
a mechanism operates. It is especially useful for illustrating the opera- 
_tional definitions of communication architectures. Finite state machines 
exist in many forms; the following describe how to read the finite state 
machine form used in defining the QLLC architecture. The reader must 
refer to the following pages, which show the QLLC finite state machine 
(QLLC_ FSM), while reading the below example and generic description. 


Example: A Reading of the QLLC Finite State Machine (QLLC_FSM) 


Suppose we are in state 04, the CLOSING state, and receive an input of 
Packet Layer Ready. The FSM changes to state 02, the CLOSED state, 
and performs procedure D. Looking below the matrix, in the column 
OUTPUT CODE, we find the letter D. Now looking to the right of D, in the 
Function column, we find the procedure to be performed: Report status. 
After the procedure is performed the reader exits from the FSM, leaving 
the FSM in state 02, the CLOSED state. — : 


Generic Description: How to Read a finite state machine (FSM) 


To find the actions performed when a certain event takes place, cross- 
reference the appropriate input with the current state. At the intersection 
is an action code, which consists of a next state indicator and an output 
code. The next state indicator is either ‘-’, meaning no state change takes 
place, or a number, which represents the new state. The output code, an 
alphanumeric identifier, references the output code section located 
directly after the matrix. Adjacent to the output codes are the functions to 
be performed. 


When the FSM is first activated it is placed in state 01, the initial state. In 


the QLLC finite state machine the initial state is the inoperative (INOP) 
state. 
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Function: 


QLLC_FSM is a finite state machine that represents the logical link connection 
between adjacent SNA nodes. The machine consists of states, inputs, output 
codes, and functions. 


The initial state of the finite state machine is the INOP state. The states are 
described in “Elements of Procedure” on page O-3. 


There are three kinds of input: external stimuli, commands and responses, and 
state change events. For a description of the external stimuli see “External 
Stimuli” on page O-6; for commands and responses see “QLLC Commands and 
Responses” on page O-9. The state change events are the bottom entries in the 
inputs column of the FSM, each beginning with Go to. 


The output codes are symbols such as, A, F, HH, and S, that are in the matrix and 
also in the left column below the matrix. They are simply a tag to identify which 
function to perform. 


The functions, which are procedures to be executed, are in the right column 
below the matr‘x. Within the functions are procedural statements that describe 
the work to be performed by the particular function. Some procedural statements 
are terse and those that are not self explanatory are further defined in “Function 
descriptions’ on page O-13. 


Within the functions, the terms PEER, PRIMARY, and SECONDARY are used to 
show that what follows each term applies to the station if it is a peer, primary, or 
secondary, respectively. 


References to notes are occasionally stated in the functions. The descriptions of 
the notes are: 


Note 1 - An exchange of QLLC link station identification information is required _ 
prior to link setup. (Some DTEs require an exchange of QLLC link station identifi- 
cation information prior to link setup while other DTEs do not.) 


Note 2 - The virtual call (switched virtual circuit) supporting the link connection is 
cleared by a packet layer CLEAR REQUEST or CLEAR_INDICATION; the under- 
lying virtual circuit is terminated; and the QLLC link connection is placed in the 
inoperative (INOP) state. Notice that this comment is only true for SVCs and is 
not true for PVCs. | 
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“Packet_Layer Ready 
Link Start 

r Link Stop — 
Packet _Layer_Inoperative 
Erroneous_QLLU | 
Exchange Identification | 
Link Test | —_ 
Send_Data 
Virtual_Circuit_Clear Reset 
Link _Timeout_Expiration _ 
Receive Data ae 
Q Receive Ready 
Q Set_Mode : 

-@ Disconnect | 

| Q_Unnumbered_ Acknowledgement tl 
@ Request Disconnect CO 
@ Disconnected Mode 
Q Frame Reject. —_ 
@_XID_Command 

[ @_XID_Response. ; 

| @ Test_Command - 
Q@_Test_Response _ 


Go_to_INOP state 


Go_to_CLOSED_state 


Go_to_ OPENING state 

| Go to CLOSING state 
Go _to_R ECOVERY state | 
Go to OPEN ED state 


Function 


= enone, panna 


Logical link is now operational. 
Set predicate condition to NULL 
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AA‘ 


AA2 


PEER & PRIMARY 
If the virtual circuit is a PVC then 
If predicate condition is NULL then 
Set predicate condition to RRp 
OR: Pass the cause and diagnostic information to higher layer 
Go to CLOSED state 
Else Set predicate condition to NULL 
Transfer Q_Set_Mode to the remote logical link station 
Else Pass the cause and diagnostic information to higher layer 
Go to the inoperative (INOP) state 


SECONDARY 
Pass the cause and diagnostic information to higher layer 
If the virtual circuit is a PVC then 
Set predicate condition to NULL 
Go to CLOSED state 
Else go to inoperative (INOP) state 


PEER 
Remote Error 
OR: Report Status 
Transfer Q Frame_Reject 


PRIMARY 
(Primary does not have a RECOVERY state.) 


SECONDARY 
Remote Error 
Transfer Q Frame_Reject 
OR: Report Status 
Transfer Q Frame_Reject 
Go to CLOSED state 


PEER & PRIMARY 

Report Status 

Set predicate condition to NULL 

Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 


Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY state 


PEER, PRIMARY, & SECONDARY 
Local Error 
(Primary does not have a RECOVERY state.) 
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Function 


PEER, PRIMARY, & SECONDARY 
Report Status | 
Set predicate condition to NULL 


PEER, PRIMARY, & SECONDARY 
Pass the cause and diagnostic information to higher. layer 
If the virtual circuit is a PVC then 
Set predicate condition to NULL 
Else go to inoperative (INOP) state 


PEER & PRIMARY 
Set predicate condition to NULL 
Transfer Q Set Mode | 
Go to OPENING state 
OR: (See note 1) 
If predicate condition is SMp then 
Transfer Q Set_Mode 
set predicate condition to NULL 
Go to OPENING state 
Else Local Error 


SECONDARY 
Secondary is now in a condition to accept a Q Set_Mode Command. 
Go to OPENING state 


CC PEER & PRIMARY 
Remote Error | 
SECONDARY 
If predicate condition is CTp then 
Report Status 
Set predicate condition to NULL 
Go to OPENED state 
Else Report Status 
Ignore Logical Link Unit 
OR: Remote Error 


PEER, PRIMARY, & SECONDARY 
Report Status 
(Primary does not have a RECOVERY state.) 


PEER & PRIMARY 
Ignore Logical Link Unit 
SECONDARY 
If predicate condition is CTp then 
Report Status 
Set predicate condition to NULL 
Go to OPENED state | 
Else 
Ignore Logical Link Unit 
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Output | Function 
Code 


PEER, PRIMARY, & SECONDARY 
Pass cause and diagnostic information to higher layer 
lf the virtual circuit is a PVC then 
Set predicate condition to NULL 
Go to CLOSED state 
Else go to inoperative (INOP) state 


DD1 PEER & SECONDARY 
Report Status 
Set predicate condition to NULL 
Transfer Q Disconnected Mode 


PRIMARY | 
(Primary does not have a RECOVERY state.) 


+ PEER, PRIMARY, & SECONDARY 


+ Remote Error 
EE PEER 


If predicate condition is OXRp or OTRp then 
Report Status 
; Set predicate condition to NULL 
; Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
Else Transfer Q Unnumbered_Acknowledgement 
OR: (See note 1) 
If predicate condition is SMp then 
Transfer Q Set_Mode | 
Set predicate condition to NULL 
Go to OPENING state 
Else Local Error 


PRIMARY 
Remote Error 


SECONDARY 
If predicate condition is OXRp or OTRp then 
Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
Else Report Status | 
Transfer Q Unnumbered_ Ack 
Go to OPENED State 
OR: Set predicate condition to CTp 
Transfer Q Unnumbered_ Ack 
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Output | Function 
Code 


EE1 


PEER & SECONDARY 
Report Status | 
set predicate condition to NULL 

Transfer Q Unnumbered Acknowledgement 


PRIMARY 
(Primary does not have a RECOVERY state.) 


PEER | 

When predicate condition is : 

NULL - Set predicate condition to IXRp 
Transfer Q XID Command 

OXRp - Set predicate condition to SMp 
Transfer Q XID Response 

lIOXRp - Set predicate condition to IXRp 
Transfer Q XID Response 


OTRp - Set predicate condition to IXOTRp 
Transfer Q XID Command 
SMp - Set predicate condition to IXRp 


Transfer Q XID_Command. 
Otherwise - Local Error 


PRIMARY 

If predicate condition is IXRp or ITRp then 
Local Error | 

Else Set predicate condition to IXRp 

Transfer Q XID Command 


| SECONDARY 

If predicate condition is OXRp then 
set predicate condition to NULL 
Transfer Q XID Response 

Else Local Error 
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Output | Function 
Code 


| 3 


Report Status 
If predicate condition is OXRp or OTRp then 
set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
Else Transfer Q Disconnected Mode 
Set predicate condition to NULL 
Go to CLOSED state 


PRIMARY 
Remote Error 


SECONDARY 

Report Status 

Transfer Q Disconnected Mode 
Go to CLOSED state 


~ PEER 
If predicate condition is OXRp, ITOXRp, or IOXRp then 
Set predicate condition to NULL 
Transfer Q XID_Response 
Else Local Error 


PRIMARY 
Local Error 


SECONDARY 

If predicate condition is OXRp then 
set predicate condition to NULL 
Transfer Q XID Response 

Else Local Error 


PEER & SECONDARY 

If predicate condition is OXRp then 
Set predicate condition to NULL 
Transfer Q XID Response 

Else Local Error 


PRIMARY 
Local Error 
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Output | Function 


PEER 

When predicate condition is : 

NULL - Set predicate condition to IXRp 
Transfer Q XID Command 

OXRp - Set predicate condition to NULL 
Transfer Q XID Response 

OTRp - Set predicate condition to.IXOTRp 
Transfer Q XID Command | 

ITOXRp-~ - Set predicate condition to ITRp 
Transfer Q XID Response 

Otherwise - Local Error 


PRIMARY | 
If predicate condition is IXRp or ITRp then 
Local Error 
Else Transfer Q XID Command 
Set predicate condition to IXRp 


SECONDARY 

If predicate condition is OXRp then 
Set predicate condition to NULL 
Transfer Q XID Response 

Else Local Error 


PEER & SECONDARY 
Remote Error 
Transfer Q Frame_Reject 


PRIMARY 
(Primary does not have a RECOVERY state.) 


FF2 PEER 
Inform Higher Layer 
Set predicate condition to NULL 
Go to CLOSED state 


PRIMARY 


(Primary does not have a RECOVERY state.) 


SECONDARY. 
Remote Error 
Transfer Q Frame_Reject 
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GG 


G1 


Function 


PEER 

When predicate condition is : 

NULL - Set predicate condition to ITRp 
Transfer Q TEST Command 

OXRp - Set predicate condition to ITOXRp 
Transfer Q TEST Command 

OTRp - Set predicate condition to NULL 
Transfer Q TEST Response 

lOTRp ~~ - Set predicate condition to ITRp 
Transfer Q TEST Response 

IXOTRp  - Set predicate condition to IXRp 
Transfer Q TEST Response 

SMp - Set predicate condition to ITRp 
Transfer Q TEST Command 

Otherwise - Local trror 


PRIMARY 
If predicate condition is IXRp or ITRp then 
Local Error 
Else set predicate condition to ITRp 
Transfer Q TEST Command 


SECONDARY 

lf predicate conditon is OTRp then 
Set predicate condition to NULL 
Transfer Q TEST Response 

Else Local Error 


PEER 
Report Status 
Go to OPENED state 


PRIMARY 
Report Status 
Go to OPENED state 


OR Report Status 
Transfer Q Receive Ready 
Go to OPENED state 


SECONDARY 
Remote Error 


PEER & SECONDARY 

If predicate condition is OTRp, lIOTRp, or IXOTRp then 
set predicate condition to NULL 
Transfer Q TEST Response 

Else Local Error 


PRIMARY 
Local Error 
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Function 


PEER & SECONDARY 

If predicate condition is OTRp then 
Set predicate condition to NULL 
Transfer Q Test_Response 

Else Local Error 


PRIMARY 
Local Error 


PEER 

When predicate condition is: _ 

NULL - Set predicate condition to ITRp 

| Transfer Q TEST Command 

OXRp - Set predicate condition to ITOXRp 
Transfer Q TEST Command . 

OTRp - Set predicate condition to NULL 
Transfer Q TEST Response 

IXOTRp ~~ - Set predicate condition to IXRp 
Transfer Q TEST Response 

Otherwise - Local Error 


PRIMARY 
If predicate condition is IXRp or ITRp then 
Local Error 
Else Transfer Q TEST Command 
Set predicate condition to ITRp 


SECONDARY 

If predicate condition is OTRp then 
set predicate condition to NULL 
Transfer Q TEST Response 

Else Local Error 


PEER & SECONDARY 
Local Error 


GG1 


PRIMARY 
(Primary does not have a RECOVERY state.) 


PEER 
Remote Error 


PRIMARY 
(Primary does not have a RECOVERY state.) 


SECONDARY 
Ignore Logical Link Unit 
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PEER & SECONDARY 
Remote Error 


PRIMARY 
Inform Higher Layer 


PEER & SECONDARY 
Local Error 


PRIMARY 
(Primary does not have a RECOVERY state.) 


PEER & PRIMARY 
Report Status 
Set predicate condition to NULL 
Go to CLOSED state 
SECONDARY 

+ Remote Error 


J PEER, PRIMARY, & SECONDARY | 
Remote Error 


JJ PEER & PRIMARY 
inform Higher Layer 


SECONDARY 
Remote Error 


PEER & SECONDARY 
Remote Error 
Transfer Q Frame_Reject 


PRIMARY 


(Primary does not have a RECOVERY state.) 


PEER & SECONDARY 
Remote Error 
Transfer Q Frame_Reject 


PRIMARY 
(Primary does not have a RECOVERY state.) 
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Function 


PEER 
If predicate condition is NULL then 
Report Status 
Transfer Q Disconnected Mode 
Else 
If predicate condition is SMp then 
Inform Higher Layer 
Else Remote Error 


PRIMARY 
Remote Error 


SECONDARY 
If predicate condition is OXRp or OTRp then 

Remote error | 

set predicate condition to NULL 

Request Packet Layer to clear SVC or reset PVC 
Else transfer Q Disconnected Mode 


PEER 
If predicate condition is NULL or SMp then 
Report Status 
Transfer Q Disconnected Mode 
Else | 
Remote Error 


PRIMARY 
Remote Error 


SECONDARY 
Set predicate condition to NULL 
Transfer Q Disconnected Mode 


PEER & PRIMARY 
Remote Error 


SECONDARY 
Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY state 
OR: Report Status 
Transfer Q Frame_Reject 
Go to CLOSED state 


PEER 
If predicate condition is NULL then 
Ignore Logical Link Unit 
Else 
Remote Error 


PRIMARY & SECONDARY 
Remote Error 
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Output | Function 
Code 


| PEER & SECONDARY 
+ Remote Error 


PRIMARY 
Remote Error 
Transfer Q Disconnect 


PEER, PRIMARY, & SECONDARY 
Timeout processing is handled as in SDLC | | 
P 


PEER 
lf predicate condition is NULL then 
Ignore Logical Link Unit 
Else 
Remote Error 


PRIMARY 
Ignore Logical Link Unit 
set predicate condition to NULL 


SECONDARY 
oF Remote Error 


\ PEER, PRIMARY, & SECONDARY 
é Pass BTU to higher layer 


PEER & PRIMARY . 
If predicate condition is IXRp or ITRp then 
Local Error 
Else Report Status 
Transfer Q Disconnect 
Go to CLOSING state 


SECONDARY 
Report Status 
Transfer Q Request Disconnect 
Go to CLOSING state 


PEER & PRIMARY 
Inform Higher Layer 


SECONDARY 
=f Remote Error 
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+++ 


++++4+44 


Function 


| Output 
Code | 


PEER 
Report Status 
Transfer Q Disconnected Mode 
Go to CLOSED state 


PRIMARY 
Report Status 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 
Report Status 
Transfer Q Request_Disconnect 
OR: Transfer Q Request Disconnect 


PEER 

When predicate condition is : 

NULL = Set predicate condition to OXRp 
Pass XID information to higher layer 

IXRp = - Set predicate condition to |OXRp 
Pass XID information to higher layer 

SMp _ - Set predicate condition to OXRp 
Pass XID information to higher layer 

Otherwise - Remote Error 


PRIMARY 
Pass XID data to higher layer 
OR: Remote Error 


SECONDARY 
If predicate condition is OTRp then 
Remote Error 
OR: Ignore Logical Link Unit 
Else 
Pass XID data to higher layer 
set predicate condition to OXRp 


PEER & SECONDARY 

Report Status 

set predicate condition to NULL 

Transfer Q Unnumbered Acknowledgement 
PRIMARY 

Report Status 

Request Packet Layer to clear SVC or reset PVC 
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+++ + 


Output 
Code 
R1 


R2 


R3 


Function 


PEER 
~ When predicate condition Is : 
NULL - Pass test data to higher layer 
set predicate condition to OTRp 


ITRp - Pass test data to higher layer 
Set predicate condition to IOTRp 

SMp - Pass test data to higher layer 
Set predicate condition to OTRp 

IXRp - Pass test data to higher layer 


Set predicate condition to IXOTRp 
Otherwise - Remote Error 


PRIMARY 
Pass test data to higher layer 
OR: Remote Error 


SECONDARY 

If predicate condition is OXRp then 
Remote Error 
OR: Ignore Logical Link Unit 

Else 
Set predicate condition to OTRp 
Pass test data to higher layer 
OR: Transfer Q Test_Response 


PEER 
If predicate condition is OXRp or OTRp then 
Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
Else Ignore Logical Link Unit 


PRIMARY 
Remote error 


SECONDARY 
Inform Higher Layer 
set predicate condition to OXRp 


PEER & SECONDARY 
Pass test data to higher layer 
set predicate condition to OTRp 
OR: Remote Error 


PRIMARY 
Remote error 
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tt Fetter +t 4 


+ +++ 


Output | Function 


Code 


PEER 
Report Status 
Transfer Q Disconnected Mode 
Set predicate condition to NULL — 
Go to CLOSED state 


PRIMARY 
Remote error 


SECONDARY 
Pass XID data to higher layer 
Set predicate condition to OXRp 


PEER 
Report Status 
Transfer Q Disconnected Mode 
Set predicate condition to NULL 
Go to CLOSED state 


RS 


PRIMARY 
Remote error 


SECONDARY 
Pass test data to higher layer 

Set predicate condition to OTRp 
OR: Transfer Q Test_Response 
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Output | Function 
Code 
R6 PEER 
When predicate condition is : 
NULL - Set predicate condition to OXRp 
Pass XID data to higher layer 
IXRp - Set predicate condition IOXRp 
Pass XID data to higher layer 
OXRp - Report Status 
Set predicate condition to NULL 
Go to CLOSED state 
lOXRp ~~ - Report Status 
set predicate condition to NULL 
Go to CLOSED state 
ITRp - Pass XID data to higher layer 
set predicate condition to ITOXRp 
Otherwise - Repon Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


PRIMARY 
Set predicate condition to NULL 
Pass XID data to higher layer 


SECONDARY 
If predicate condition is OTRp then 
Report Status 
Set predicate condition to NULL 


Transfer Q Disconnected_Mode 
Go to CLOSED state 
Else Inform Higher Layer 
Set predicate condition to OXRp 
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Function 


Output 
Code 


R7 PEER 
When predicate condition is : 
NULL - Set predicate condition to OTRp 
Pass test data to higher layer 
IXRp - Set predicate condition to IXOTRp 
Pass test data to higher layer 
ITRp - Set predicate condition to lIOTRp 
Pass test data to higher layer 
Otherwise - Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
OR: Transfer Q Test Response © 


PRIMARY 
lf predicate condition is ITRp then 
set predicate condition to NULL 
Pass test data to higher layer 
Else Report Status | 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


++++4+4+4 


SECONDARY 
lf predicate condition is OXRp then 
Report Status . 
Set predicate condition to NULL 
Transfer Q Disconnected _Mode 
Go to CLOSED state 
Else set predicate condition to OTRp 
Pass test data to higher layer 
OR: Report Status 
Transfer Q Test_Response 
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Output | Function 


RR‘ PEER 
Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY State 


PRIMARY 
Report Status 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 

Report Status 

Transfer Q Frame_ Reject 

Go to RECOVERY state 

OR: Report Status 
Transfer Q Frame_Reject 
Set predicate condition to NULL 
Go to CLOSED state 


S PEER 

When predicate condition is : 

IXRp - Pass XID data to higher layer 
Set predicate condition to SMn 

lIOXRp - Pass XID data to higher layer 
Set predicate condition to OXRp 

IXOTRp- - Pass XID data to higher layer 
Set predicate condition to OTRp 

Otherwise - Remote Error 


PRIMARY 
If predicate condition is IXRp then 
Set predicate condition to SMp 
Pass XID data to higher layer 
Else 
Pass XID data to higher layer 


SECONDARY 
Remote Error 


SS PEER & PRIMARY 
Report Status 
Set predicate condition to NULL 
Go to CLOSED state 


SECONDARY 
Report Status 
Transfer Q Frame_Reject 
Go to RECOVERY state 
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Function 


When predicate condition is: 

ITRp - Pass test data to higher layer 
Set predicate condition to NULL 

lOTRp, - Pass test data to higher. layer 
Set predicate condition to OTRp 

ITOXRp~ - Pass test data to higher layer 
Set predicate condition to OXRp 

Otherwise - Remote Error 


PRIMARY 
If predicate condition is ITRp then 
Pass test data to higher layer | 
set predicate condition to NULL 
Else 
Remote Error 


SECONDARY 
Remote Error 


S2 PEER 
If predicate condition is IXRp then 
Pass XID data to higher layer 
Set predicate condition to NULL 
Else Remote Error 
PRIMARY 
Remote error 
* SECONDARY ee 
+ Remote Error 


PEER 
If predicate condition is ITRp then 
Pass test data to higher layer 
set predicate condi:ion to NULL 
Else Remote Error 


++ ++4++4+4++4 
ae. 


PRIMARY 
Remote error 


SECONDARY 
Remote Error 


S4 PEER 
Ignore Logical Link Unit 
PRIMARY 
Remote Error 
| SECONDARY 
+ Remote Error 
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Output | Function 


Code 
+{ §5 PEER 
+ Ignore Logical Link Unit 
+ PRIMARY 
Se Remote error 
+ SECONDARY 
+ Remote Error 
s§ PEER 


When predicate condition is : 

IXRp - Set predicate condition to NULL 
Pass XID data to higher layer 

IOXRp ~~ - Set predicate condition to OXRp 
Pass XID data to higher layer 

IXOTRp- - Set predicate condition to OTRp 
Pass XID data to higher layer 

Otherwise - Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


PRIMARY 
If predicate condition is IXRp then 
Set predicate condition to NULL 
Pass XID data to higher layer 
Else Report Status 
set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 
Remote Error 
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Output 
Code 


+ 


++++ 
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S/ 

SS1 

TT 

UU 

UU1 | 


Function 


PEER 


When predicate condition is : 

ITRp - Set predicate condition to NULL 
Pass test data to higher layer 

ITOXRp ~~ - Set predicate condition to OXRp 
Pass test data to higher layer 

lOTRp ~ - Set predicate condition to OTRp 
Pass test data to higher layer 

Otherwise - Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


PRIMARY 


If predicate condition is ITRp then 
Set predicate condition to NULL 
Pass test data to higher layer 
Else Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 


Remote Error 


PEER, PRIMARY, & SECONDARY 
Transfer Data Logical Link Unit 


PEER 


Remote Error 


PRIMARY 
Report Status 
OR: Ignore Logical Link Unit 


SECONDARY 


Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY state 


PEER & PRIMARY 


set predicate condition to NULL 
Report Status 
Go to CLOSED state 


SECONDARY 


Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY state 


PEER, PRIMARY, & SECONDARY 7 
Pass BTU to higher layer 2 
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Output | Function 


PEER 
Ignore Logical Link Unit 


PRIMARY | 
Report Status 


Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 


SECONDARY 
Report Status 
Transfer Q Frame_ Reject 
Go to RECOVERY state 


VV 1 PEER & SECONDARY 
Report Status 
Transfer Q Disconnected Mode 
Set predicate condition to NULL 
Go to CLOSED state 


PRIMARY 
Report Status 
Request packet layer to clear SVC or reset PVC 
Set predicate condition to NUL 7 
Go to CLOSED state 


W PEER 
If Predicate condition is RRp then 
Report Status 

Else Local Error 

PRIMARY 
Local Error 

SECONDARY 
Local Error 


WW1 PEER & SECONDARY 
Report Status 
Transfer Q Unnumbered_Acknowledgement 
Set predicate condition to NULL 
Go to CLOSED state 


PRIMARY 
Report Status 
Set predicate condition to NULL 
Request Packet Layer to clear SVC or reset PVC 
Go to CLOSED state 
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XX1 
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Function 


PEER & PRIMARY 
Local Error 


SECONDARY | 
Report Status 
set predicate condition to NULL 

Go to CLOSED state 


PEER 
Transfer Q Set_Mode 


PRIMARY 
(Primary does not have a RECOVERY state.) 


SECONDARY 
set predicate condition to NULL 


PEER & PRIMARY 
Remote Error 


SECONDARY 
Report Status 
Transfer Q Frame_Reject 
Go to RECOVERY state 


PEER | 
Transfer Q Disconnect 


PRIMARY 
(Primary does not have a RECOVERY state.) 


SECONDARY 
Transfer Q Request_Disconnect 


PEER & SECONDARY 
Report Status 
Transfer Q Frame_Reject 

Go to RECOVERY state 


PRIMARY 
Report Status 

_ Transfer Q Disconnect 

Go to CLOSING state 
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Appendix V. Addresses in Call Set-up and Clearing 


Packets 


» V.1 Main address and complementary address 


> 
> 


A DTE address may include two components: a main address and a com- 
plementary address. 


>V.1.1 Main address 


- 
> 
> 


V . 


VVVVV 


When the A bit is set to ‘0’", the main address is conforming to formats 
described in CCITT Recommendation X.121 and X.301 (including possible 
prefixes and/or escape codes). 


When the A bit is set to ‘1’, the main address is as described below. 


Type of address | Numbering plan Address digits 
identification 


|-1 semi-octet—>|<—1 semi-octet+| 


The possible values and the semantic of these subfields are described in 
section 9.2.1.2. 


>V.1.2 Complementary address 


> 
> 
> 


VVVV VVVVV 


VV 


V 


A complementary address is address information additional to that 
defined in CCITT Recommendation X.121 (see section 6.8.1 of CCITT 
Recommendation X.301). 


some networks allow the DTE to include a complementary address. When 


a complementary address is permitted by the network, the DTE is not 
obliged to use this complementary address. The complementary address 
may be as long as possible in considering the maximum value of the DTE 
address length fields defined in sections 5.2.1.1 and 5.2.1.2. 


When a complementary address is contained in a DTE address field of a 


packet transmitted by the network to the DTE, this complementary address 


is always passed transparently from the remote DTE: it means that the 
network never creates a complementary address from itself. 


When a complementary address is invoked in the following sections, it is 
supposed that the network supports the use of complementary address. 


When the A bit is set to ‘1’ and a complementary address is present alone 


(i. e., without main address) in a DTE address field, it is preceded by the 
type of address and numbering plan identification subfields. 
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> V.2 Address in CALL REQUEST packet 


V 


VVVYV 


VVVVVVVVVV VV 


V 


VV V 


VVVYV 


VVVVVVVVVV VV VV VOY 


V 


VV 


In CALL REQUEST packet, the called DTE address should be provided by 
the DTE except when the Bilateral _ Closed User Group Selection is pro- 
vided in the facility field (see section 6.15.3). Depending on the called 
network and the DTE, this called DTE address may be made of a main 
address then a complementary address, or of a main address alone. 


Depending on the network, the DTE may have the following possibilities 
for the calling DTE address: 


e The DTE may include either no calling DTE address, or a main 
address optionally followed by a complementary address. When a 
calling DTE address is provided by the DTE, the network is required to 
check its validity. If the calling DTE address is not valid, the network 
may either replace this invalid calling DTE address by a valid one, or 
clear the call. If the Hunt_Group facility has been subscribed to by the 
calling DTE (see section 6.24) and a specific address has been 
assigned 19 the calling DTE/DCE interface, the main address provided 
by the calling DTE may be the hunt group address or the specific 
address. 


Note: 


In this later case, some networks do not allow the calling DTE 
to indicate the hunt group address, but only the specific 
address. 


e The DTE may include either no calling DTE address, or a calling com- 
plementary address. In this last case, when the A bit is set to ‘1’, this 
complementary address shall be preceded by the type of address and 
numbering plan identification subfields. 


V.3. Address in INCOMING CALL packets _ 


In INCOMING CALL packet, the calling DTE address should be provided 
by the DCE except when the Bilateral. Closed User _Group_ Selection is 
provided in the facility field (see section 6.15.3) or in one case described 
in section 6.28. This calling DTE address always includes a main address. 
This main adaress is followed by a calling complementary address if such 
a complementary address had been provided by the calling DTE in the 
CALL REQUEST packet, and the calling DTE address was considered as 
valid by the network at the calling DTE side. If the Hunt_Group facility has 
been subscribed to by the calling DTE (see section 6.24) and a specific 
address has been assigned to the calling DTE/DCE interface, the main 
address indicated in the calling DTE address field may be the hunt group 
address (only if the calling DTE had indicated either its hunt group 
address or no main address, in the calling DTE address field of the 

CALL REQUEST packet) or the specific address (regardless of the con- 
tents of the calling DTE address field in the CALL REQUEST packet). 


Depending on the network, the called DTE address may be made of: 


e The main called address optionally followed by the called complemen- 
tary address if this complementary address had been provided by the 
calling DTE. If the Hunt_Group facility has been subscribed to by the 
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VVVVV VVVVV VV 


VVVYV 


V 


VVVV VVVVVVVV YV 


VVVVV VV VV 


VVV Vv 


VV 


called DTE (see section 6.24) and a specific address has been 
assigned to the called DTE/DCE interface, the main address indicated 
in the called DTE address field may be the hunt group address (only if 
the calling DTE had indicated this hunt group address or no main 
address, in the calling DTE address field of the CALL REQUEST 
packet) or the specific address (regardless of the contents of the 
calling DTE address field in the CALL REQUEST packet). 


« The called complementary address alone when provided by the calling 
DTE, or nothing if the calling DTE had not provided this called comple- 
mentary address. When a called complementary address is alone and 
the A bit is set to ‘1’, the called complementary address is preceded 
by the type of address and numbering plan identification subfields. 


V.4. Address in CALL_ACCEPTED packets 


Some networks do not allow any DTE addresses in CALL_ACCEPTED 
packets except a called DTE address in conjunction with the 

Called Line Address Modified Notification facility when supported by the 
network and provided by the DTE. 


Some other networks allow the DTE to include in the CALL_ACCEPTED 
packet none, one or both of the two DTE addresses. When provided by 
the DTE, the calling DTE address in the CALL_ ACCEPTED packet should 
be the same as the calling DTE address in the INCOMING CALL packet. 
When provided by the DIE, tne calied DTE address in the 

CALL ACCEPTED packet should be the same as the called DTE address in 
the INCOMING CALL packet, except if the 

Called Line Address Modified Notification facility (when supported by the 
network) is also provided by the DTE. 


When the Called Line Address Modified Notification facility (when sup- 
ported by the network) is provided by the DTE in the CALL ACCEPTED 
packet, the called DTE address may be made of one of the following 
exclusive network dependent possibilities: 


« A main DTE address identical to that of the INCOMING CALL packet, 
followed by a called complementary address different from that of the 
INCOMING CALL packet, or another main DTE address valid for the 
DTE/DCE interface optionally followed by any complementary address. 


e Acalled complementary address, different from that which was pos- 
sibly present in the called DTE address of the INCOMING CALL 
packet. In this case, when the A bit is set to ‘1’, the called comple- 
mentary address shall be preceded by the type of address and num- 
bering plan identification subfields. 


V.5 Address in CALL CONNECTED packets 


some networks do not provide any DTE address in CALL_CONNECTED 
packets except a called DTE address in conjunction with the 
Called Line Address Modified Notification facility. 


Some networks always provide both DTE addresses in CALL_ CONNECTED 
packets. 
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Some other networks provide a DTE address in a CALL_CONNECTED 
packet only if this DTE address was present in the CALL_ ACCEPTED 
packet or in conjunction with the 

Called Line Address Modified Notification facility. 


VVVV 


In any case, when an address is provided by the network in the 

CALL CONNECTED packet, this address should be the same as that in the 
CALL REQUEST packet except when the 

Called Line Address Modified Notification facility is present in the facility 
field: in this case, the called DTE address always contains a main address 
optionally followed by a complementary address. 


VVVVVV 


> V.6 Address in CLEAR_REQUEST packets 


No address is permitted in CLEAR REQUEST packets except a called DTE 
address when the Called Line Address Modified Notification facility (see 
section 6.26) is used in this packet. In this case, the CLEAR REQUEST 
packet is transmitted as a direct response to the INCOMING CALL packet 
and the called DTE address may be made of one of the following network 
dependent possibilities: 


VVVVVYV 


e A main DTE address identical to that of the INCOMING CALL packet, 
followed by a called complementary address different from that of the 
INCOMING CALL packet, or another main DTE address valid for the 
DTE/DCE interface. 


VVVV 


e A called complementary address, different from that which was pos- 
sibly present in the called DTE address of the INCOMING CALL 
packet. In this case, when the A bit is set to ‘1’, the called comple- 
mentary address shall be preceded by the type of address and num- 
bering plan identification subfields. 


VVVVV 


V./ Address in CLEAR_INDICATION packets 


No address is permitted in CLEAR_INDICATION packets except when the 
Called Line Address Modified Notification facility (see section 6.26) is 
used in this packet. In this case, the CLEAR_INDICATION packet is trans- 
mitted as a direct response to the CALL_REQUEST packet and the called 
DTE address always contains a main address optionally followed by a 
complementary address. 


VVVVV VV 


> V.8 Address in CLEAR_CONFIRMATION packets 
> DTE addresses are not present in CLEAR_CONFIRMATION packets. 


»V.9 Addresses in Call_Redirection and Call_ Deflection facilities 


The alternative DTE address, indicated at subscription-time (for the 

Call Redirection facility) or in the Call Deflection Selection facility of the 
CLEAR REQUEST packet {see sections 6.25.1 and 6.25.2), is composed of 
a main address optionally followed by a complementary address. 


VV VV 
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If a called complementary address was present in the CALL REQUEST 
packet, some networks may add this called complementary address after 
the alternative DTE address. 
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